210 likes | 298 Views
Authorization in Oracle Part 2 Ji-Won Mahesh. Stored Procedures. If A gives B insert on t with no grant option Can only B can insert into t? No – must consider whether B has the “create procedure” (or “create any procedure”) system privilege. Examples.
E N D
Stored Procedures • If A gives B insert on t with no grant option • Can only B can insert into t? • No – must consider whether B has the “create procedure” (or “create any procedure”) system privilege.
Examples create or replace procedure def(x number, y number) [authid definer] as begin insert into alice.t1 values (x,y); commit; end; / Bob.def create or replace procedure inv(x number, y number) authid current_user as begin insert into alice.t1 values (x,y); commit; end; / Bob.inv
Definer’s rights procedure • “A user…requires only the privilege to execute the procedure and no privileges on the underlying objects…” • “…operates under the security domain of the user who owns the procedure…” • “At runtime, the privileges of the owner…are always checked…”
Invoker’s rights procedure • “…executes with all of the invoker’s privileges…” • “…invoker needs privileges at runtime to access…DML or dynamic SQL statements, because they are effectively recompiled at runtime.” • “For…direct PL/SQL function calls, the owner’s privileges are checked at compile time, and no runtime check is made. Therefore, the user…needs no privileges…outside DML or dynamic SQL statements.”
Examples create or replace procedure def_inv(x number, y number) as begin bob.inv(x,y); end; / Carl.def_inv • Similarly: Carl.inv_inv, Carl.inv_def, …
def_inv A B inv def_inv C D
inv_inv A B inv inv_inv C D
inv_def A B def inv_def C D
Understanding Java Stack Inspection OS Trusted Java “The system” Untrusted Java
Java Access Control • Consequences of type safety • Old approach: sandbox • New approach: stack inspection • Assume access matrix, with subjects = signors/classes (?), and objects = resources
Stack Inspection • Frame has: • Arguments • Local vars. • Ret. Addr. Annotated with: enable_privs(t) (Assumptions about who may do this) Newest frame, Or current frame
Primitives • enable_privilege(t) • disable_privilege(t) • Explicit denial • revert_privilege(t) • Removal of annotation • check_privilege(t)
check_privilegeF(t) check_privilege(t) { foreach stackFrame { if (local policy forbits access to t by the class executing in stackFrame) deny access; if (stackFrame has enabled priv. for t) return; // allow access if (stackFrame has disabled priv. for t) deny access; } Default: • Netscape: deny • Sun/Microsoft: allow
ABLP Logic • If s is an instance of a theorem in propositional logic, then s is true in ABLP • (Atomic) principals, statements • Connectives: • says, , , ∧, | • Statement: eg. Ok(t) • E.g. axiom: (A says (B A)) (B A)
Decision Problem • check_privilegeF(t) ≈ EF Ok(t) ? • EF = (, AVM(F), BF) • = set of frame credentials • frame signer • AVM(F) = access matrix entries • P t • BF = belief set for the frame F
Constructing belief set • Example from the paper…
Decision Procedure • Collects all statements from (, AVM(F), BF) • Considers “type 1” statements: Ok(u) • Then considers “type 2” statements (P Q) and builds a di-graph. • Then considers “type 3” statements (F1 | F2 | … | Fk says Ok(u) ). True if both: • For all 1, …, k, Fi t in the di-graph • u = t
Decision Procedure (contd.) • Terminates • Is sound • Conjectured to be complete • Is “equivalent” to java stack inspection
Other stuff • E.g., when does call to enable_privilege(t) succeed? • Canonical form for belief set • P1 | P2 P2 | P1 • P | P P • Pushdown automata • Security-passing style: carrying around belief set in a “hidden” parameter
Other stuff (contd.) • RPC: • Caller sends to callee: • Belief set • Frame credentials • Callee prepends: • Kcaller | to every entry in belief set