22. August 2013

DB Security 12c Serie 2: PL/SQL Invoker Rights

Es gibt zwei Arten von Aufrufen für PL/SQL Funktionen:
  • Definer’s Right (AUTHID = DEFINER)
    Zur Compilezeit werden die Berechtigungen geprüft
  • Invoker’s Right (AUTHID = CURRENT_USER)
    Zur Laufzeit werden die Berechtigungen geprüft
Der wesentliche Unterschied ist, dass eine PL/SQL Funktion mit AUTHID=CURRENT_USER die Berechtigungen des Aufrufenden nutzt. Somit könnte man z.B. eine PL/SQL Funktion implementieren, die eine Aktion ausführt, für die der Entwickler keine Berechtigungen zum Zeitpunkt der Erstellung besitzt. D.h. weiter ein Entwickler kann über PL/SQL für kurze Zeit (nämlich während der Ausführung der Funktion) Berechtigungen von Benutzer ausnutzen, wie z.B. die Berechtigungen eines DBAs.

PL/SQL Beispiel: Entwickler hat nicht das CREATE USER Recht

create or replace procedure check_syntax authid current_user is
begin
execute immediate 'GRANT DBA TO ENTW1';
end;
/

PL/SQL mit AUTHID=CURRENT_USER:

Haben Sie schon einmal in Ihrer Datenbank geprüft, welches PL/SQL Funktionen und Prozeduren mit Invoker Rechten ausgeführt werden? Kennen Sie den Source-Code dieser PL/SQL-Logiken? Ja, dann sollten Sie alles unter Kontrolle haben, oder? Nein, Sie kennen nicht den Zustand, dann prüfen Sie doch einfach mal, was in Ihrer Oracle-Datenbank an PL/SQL mit Invoker Rechten existiert:

SQL Beispiel für 12c: Ermittlung der Invoker PL/SQL Logiken

select a.owner, 
       a.object_type,
       a.authid,
       b.name as CONTAINER,
       count(*)
 from cdb_PROCEDURES a,
      v$containers b
 where a.con_id =b.con_id
 group by a.owner, a.object_type, a.authid, b.name
 order by 1,2,3;

SQL Beispiel für 11g: Ermittlung der Invoker PL/SQL Logiken

select a.owner, 
       a.object_type,
       a.authid,
       count(*)
 from DBA_PROCEDURES a
 group by a.owner, a.object_type, a.authid
 order by 1,2,3;
Führen Sie doch einfach dieses Select-Statement für die entsprechende DB-Version aus. Sind Sie überrascht?

Mit der DB 12c wurde das Konzept "Invoker Rechte"angepasst

In 11g hatte der Owner - also der Ersteller - der PL/SQL-Logik die Kontrolle, zu entscheiden wie die Logik ausgeführt wird. Mit 12c wurde nun eine sinnvolle und neue Restriktion eingeführt.

Oracle prüft nun zusätzlich die Privilegien des Owners der Procedure, wenn ein Benutzer ein Invoker Right’s Procedure ausführt. D.h. der Owner muss das INHERIT PRIVILEGES Object Privileg oder INHERIT ANY PRVILEGES besitzen. Ist das nicht der Fall ist, dann wirft die Datenbank einen Fehler.
Somit kann jeder Ausführende selber entscheiden, ob seine Berechtigung zur Ausführung einer PL/SQL Logik missbraucht werden kann. 

Oracle Empfehlung für den Einsatz von INVOKER Rights in PL/SQL und Views:

  1. Immer dann wenn eine PL/SQL Procedure in einem hoch privilegierten Schema erstellt und von anderen genutzt werden soll (z.B. in einem DBA Schema). Wenn weniger privilegierte User diese Procedure aufrufen, dann können diese Benutzer zur Zeit der Ausführung mehr in der Datenbank tun, als sie tatsächlich dürfen.
    Darum empfiehlt sich eine Invoker's Rights Procedure, denn dann läuft die PL/SQL Logik mit den Rechten des Aufrufers also des Invokers..
  2. Immer dann wenn das PL/SQL kein SQL enthält und verfügbar für viele andere Nutzer sein muss, wie das Package DBMS_OUTPUT.