桃楲瑳慩歓-StaticEnforcementofSecuritywithTypes.pptVIP

Static Enforcement of Security with Types Christian Skalka and Scott Smith Johns Hopkins University Background: PL Security Non-local execution of code (e.g. Applets) presents new security problems Some PLs provide user-level abstractions for security (Ambit, Spi-calculus, Java) Built-in mechanisms allow expression and enforcement of various models/policies Varieties of Security Dataflow ensures security of data Certified Code (PCC) is an extremely general framework for extensible code security Access Control is a flexible system of code ownership and resource authorization Varieties of Security Dataflow ensures security of data Certified Code (PCC) is an extremely general framework for extensible code security Access Control is a flexible system of code ownership and resource authorization Overview Background: PL Security Java JDK 1.2 and stack inspection Using types instead of stack inspection Security Types: formal properties Possible improvements Work in Progress Conclusion Java Security Java JDK 1.2 provides a system for access control and code security possibly non-local program execution requires protection of resources All code has a specified owner, granted certain privileges locally Resources are protected by a dynamic check (stack inspection) Stack Inspection Stack frames are annotated with names of owners and any enabled privileges During inspection, stack frames are searched from most to least recent: fail if a frame belonging to someone not authorized for privilege is encountered succeed if activated privilege is found in frame Example: privileged printing privPrint(f) = (* owned by system *) { checkPrivilege(PrintPriv); print(f); } foreignProg() = (* owned by Joe *) { …; privPrint(file); …; } Stack Inspection Why Stack Inspection? How is it different from a capability system? Why not just use an access control matrix and a global set of allowable privileges? Privileges not held by current code owner are removed from allowable set S