Security Fundamentals: Models

1. Security Fundamentals: Models Trent Jaeger January 12, 2004

2. Trent Jaeger -- Background • Graduated from UM with PhD • Flexible Control of Downloaded Executable Content • Research Thread That Led to Java 2 Security Model • IBM TJ Watson Research Center 1996-Present • Operating Systems Research 1996-2001 • L4 microkernel-based systems: L4Linux, Lava, JavaOS, SawMill • Security policy: graphical access control, constraint models • Systems Security Research 2001-Present • Linux Security: based on the Linux Security Modules framework • Linux Security Analysis Project: source code and policy analysis – www.research.ibm.com/vali • Conference chair, programming chair of ACM SACMAT, CCS • PC member of IEEE S&P, USENIX, ESORICS, etc.

3. Access Control • Determine whether a principal can perform a requested operation on a target object • Principal: user, process, etc. • Operation: read, write, etc. • Object: file, tuple, etc. • Lampson defined the familiar access matrix and its two interpretations ACLs and capabilities [Lampson70]

4. Why are we still talking about access control? • An access control policy is a specification for an access decision function • The policy aims to achieve • Permit the principal’s intended function (availability) • Ensure security properties are met (integrity, confidentiality) • Limit to “Least Privilege,” Protect system integrity, Prevent unauthorized leakage, etc. • Also known as ‘constraints’ • Enable administration of a changeable system (simplicity)

5. “Simple” example • Prof Alice manages access to course objects • Assign access to individual (principal: Bob) • Assign access to aggregate (course-students) • Associate access to relation (students(course)) • Assign students to project groups (student(course, project, group)) • Prof Alice wants certain guarantees • Students cannot modify objects written by Prof Alice • Students cannot read/modify objects of other groups • Prof Alice must be able to maintain access policy • Ensure that individual rights do not violate guarantees • However, exceptions are possible – students may distribute their results from previous assignments for an exam

6. Access Control is Hard Because • Access control requirements are domain-specific • Generic approaches over-generalize • Access control requirements can change • Anyone could be an administrator • The Safety Problem [HRU76] • Can only know what is leaked right now • Access is fail-safe, but Constraints are not • And constraints must restrict all future states

7. Compare to Other CS Problems • Processor design • Hard, but can get some smart people together to construct one, fixed, testable design • Network protocol design • TCP: A small number of control parameters necessary to manage all reasonable options, within a layered architecture • Constraints, such as DDoS, are ad hoc • Software design • Specific goals in mind to achieve function, constraints are ad hoc

8. Access Hook Authorize Request? Security-sensitive Operation Access Hook Access Hook Security-sensitive Operation Security-sensitive Operation Yes/No Reference Monitor Model Entry Points System Interface Monitor Policy

9. Reference Monitor Components • Interface • Where to make access control decisions (mediation) • Which access control decisions to make (authorization) • Linux Security Modules interface • Decision function • Compute decision based on request and policy • E.g., SELinux, LIDS, DTE, etc. modules • Policy – our focus today • How to represent access control policy • Main mechanism issue – find mechanism to enable verification that policy achieves function and meets security guarantees

10. Access Control Models • Basic Access Matrix • UNIX, ACL, various capability systems • Aggregated Access Matrix • TE, RBAC, groups and attributes, parameterized • Plus Domain Transitions • DTE, SELinux, Java • Lattice Access Control Models • Bell-LaPadula, Biba, Denning • Predicate Models • ASL, OASIS, domain-specific models, many others • Safety Models • Take-grant, Schematic Protection Model, Typed Access Matrix

11. Need for Aggregate Models (RBAC) • Practical ease of specification • Abstraction for users, permissions, constraints, administration • Natural access control aggregations – based on organizational roles • As new employees join, their permission assignments are determined by their job • Permission assignment is largely static • Central control and maintenance of access rights • Flexible enough to enforce • least privilege, separation of duties, etc.

12. Type Enforcement [BoebertKain84] Permission Assignment Object User Type (Subject) Subject Type Can Access Object Type To Perform Operations On Objects Type (Object) Object User User Object

13. Group and Attributes Permission Assignment Object User User Group Has Access To Objects With the Attribute User Group Attribute Object User User Object

14. Role-based Access Control User-Role Assignment Perm-Role Assignment Role Perm Object User Users in Role Can Access Objects Using Permissions Perm Object User User Perm Object

15. Role vs. Types Data Structures • RBAC • U: set of users • P: set of permissions • Type Enforcement • E: set of subjects or objects • Permission Assignment • ST: set of subject types • OT: set of object types • O: set of operations

16. Role-based Access Control Model • Users: U • Permissions: P • Roles: R • Assignments: User-role, perm-role, role-role • Sessions: S • Function: user(S), roles(S) • Constraints: C

17. RBAC Family of Models • RBAC0 contains all but hierarchies and constraints • RBAC1 contains RBAC0 and hierarchies • RBAC2 contains RBAC0 and constraints • RBAC3 contains all • The RBAC family idea has always been more a NIST initiative • The RBAC families are present in the NIST RBAC standard [NIST2001] with slight modifications: • RBAC0, RBAC1 (options), RBAC3 (SSD) , RBAC3 (DSD)

18. Hierarchies and Constraints • Role hierarchy • Problem: does organizational hierarchy correspond to a permission inheritance hierarchy? • Problem: do organizational roles make sense for building hierarchies? • Constraints • Problem: constraints apply to all states, so they require a predicate calculus in general • Problem: Only certain types of constraints can effectively be administered? Mutual exclusion, separation of duty, cardinality, etc. • Conflicts • May find other concepts useful for resolving conflicts between constraints and hierarchies/assignments

19. Administration • Discretionary Access Control • Users (typically object owner) can decide permission assignments • Mandatory Access Control • System administrator decides on permission assignments • Flexible Administrative Management • Access control models can be used to express administrative privileges

20. Does RBAC Achieve Its Goals? • Practical ease of specification • Clear base model – need more help for constraints, admin • Natural access control aggregations – based on organizational roles • In some cases, but not clear that organizational roles help with permission assignment – particularly with inheritance • Central control and maintenance of access rights • Central view is a selling feature of products, but a single view of all can be complex (layering?) • Flexible enough to enforce • Flexible access control expression, but difficult to determine if we enforce our security goals (constraints)

21. RBAC Products • SUN Solaris • Sybase SQL Server • BMC INCONTROL for Security Management • Systor Security Administration Manager • Tivoli TME Security Management • Computer Associates Protect IT • Siemens rbacDirX

22. Safety Problem [HRU76] • Determine if an unauthorized permission is leaked given • An initial set of permissions and • An access control system, mainly administrative operations • For a traditional approach, the safety problem is undecidable • Access matrix model with multi-operational commands • Main culprit is create – create object/subject with own rights • Prove reduction of a Turing machine to the multi-operational access matrix system • Result led to • Safe, but limited models: take-grant, schematic protection model, typed access matrix model • Further support for models in which the constraints are implicit in the model – e.g., lattice models • Check safety on each policy change – constraint approach of RBAC

23. Lattice Access Control Models • Subjects and Objects have security levels and optional categories • Confidentiality Policy (e.g., Bell-LaPadula) • Simple property: may read only if the subject’s security level dominates the object’s security level (read-down) • *-property: may write only if the subject’s security level is dominated by the object’s security level (write-up) • Tranquility property: may not change the security level of an object concurrent to its use • Integrity Policy • Biba is the dual of BLP for integrity

24. Read/write Read/write Read Write Write Read Security Levels and Policies Dominance 1 > 2 > 3 L:1 BLP Operations Biba Operations L:2 L:3

25. Purpose of BLP and Biba • BLP • Prevent Trojan horses from leaking information to lower security levels • Mandatory access control and implicit constraints • Biba • Prevent low integrity information flows to higher integrity processes • E.g., code, configuration, user requests, buffer overflows • Categories/Compartments for separation within levels • Safety is implicit in the model • No additional constraints are needed to express security guarantees

26. Denning’s Lattice Model • Formalizes information flow models • FM = {N, P,SC,/,t} • Shows that the information flow model instances form a lattice • {SC, t} is a partial ordered set, • SC is finite, • SC has a lower bound, • and / is a lub operator • Implicit and explicit information flows • Semantics for verifying that a configuration is secure • Static and dynamic binding considered • Biba and BLP are among the simplest models of this type

27. Implicit and explicit flows • Explicit • Direct transfer to b from a (e.g., b = a) • Implicit • Where value of b may depend on value of a indirectly (e.g., if a = 0, then b = c) • Model covers all programs • Statement S • Sequence S1, S2 • Conditional c: S1, …, Sm • Implicit flows only occur in conditionals

28. Semantics • Program is secure if: • Explicit flow from S is secure • Explicit flow of all statements in a sequence are secure (e.g., S1; S2) • Conditional c:S1, …, Sm is secure if: • The explicit flows of all statements S1, …, Sm are secure • The implicit flows between c and the objects in Si are secure

29. Static and Dynamic Binding • Static binding • Security class of an object is fixed • This is the case for BLP and Biba • This is the case for most system models • Dynamic binding • Security class of an object can change • For b = a, then the security class of b is b / a • Rare approach

30. Model Examination • Static binding • BLP and Biba check security property at runtime • Guarantees security of all implicit and explicit flows • If a, then b = c means that a t b, so SC(a) must be dominated by SC(b) in BLP • Otherwise, information leakage • Data Mark Machine • Security class depends on location in program • Combine with condition class on entering condition • Data flow captured because c t b is checked in condition and b t a is checked outside and t is transitive • Does not hold for dynamic binding

31. Model Examination • Certification Mechanism • Static check eliminates covert channels • Limits • Language defect could miss a check (buffer overflow) • Hardware malfunction • Approach • Verify information flow w/i a statement • d = a + b; a / btd; d must dominate • Set statement security level S = d • Statement sequence S = S11S2 – must be able to flow to greatest lower bound • Verify c td1, …, dn for implicit flow

32. Verification Example TS d = PS e = MS e t d X MS PS d = TS e = MS e t d OK S = S1 1 S2 = MS c t S, c dominated by MS NS

33. Dynamic Binding • Definition • May change the security class of an object that removes it from view – could leak covertly! • Dynamic Data Mark • Combine program class with actual data flow class • Static binding mechanism doesn’t work • paper example shows that dynamic class updating does not account for implicit flows • Local object solution ensures correct classification, but seems functionally limiting • Static analysis to insert classification statements to cover implicit flows • High Water Mark • Class is raised to prevent leakage a / b whenever b = a • Similar flaw to Dynamic Data Mark – and similar fix

34. Lattice Model Features • Safe policies w/o constraints • Bell-LaPadula is consistent with military security policy • Biba is not consistent with any practical integrity policy • Problem: Downgraders/Upgraders • Changing the security label of an object requires sanitization • Remove secrets for confidentiality downgrade • Remove low integrity data for integrity upgrade • Sanitization is ad hoc • Sanitizer must be of trusted (more stringent requirement than simply being at the higher security class) • Lattice model effectiveness is limited by the number of downgraders

35. Recent Information Flow Policies • Information flow in programming languages • Andrew Myers (Cornell), Steve Zdancewic (U Penn), Barbara Liskov (MIT) • Decentralized Label Model • Flow policies of principals implemented by labeled data • System guarantees to enforce all policies simultaneously • Declassification enables remove of restrictions “where appropriate” – determined by programmer • Enables static checking • Advantage: assume programmer is trusted to describe security policies • Programmers can prevent Trojan horse leakage in downgrade

36. Decentralized Labels • Labels have owners and readers • L = {o1: r1, r2; o2: r2, r3} • Effective readers of L {r2} because only it can read from o1 and o2 • Static binding • Label of a value is forgotten when assigned to a variable • Relabeling semantics • A new label contains the owners of the old, but fewer readers • Declassification semantics • An authority for an owner can add the owner or readers of the owner • Label join/meet semantics • Join (e.g., multiply 2 numbers) Union owners and intersect readers • Meet (dual of join): Intersect owners and union readers?

37. Other Models • Plus Domain Transitions • DTE, SELinux, Java • Predicate Models • ASL, OASIS, domain-specific models, many others • Safety Models • Take-grant, Schematic Protection Model, Typed Access Matrix

38. (Ref monitor) Irvine, C.E., The Reference Monitor Concept as a Unifying Principle in Computer Security Education, Proceeding IFIP TC11 WC 11.8 First World Conference on Information Security Education , Kista, Sweden, June 1999, pp 27--37 (BLP) Bell-LaPadula: MITRE tech report – hard to find (Denning) Dorothy E. Denning: A Lattice Model of Secure Information Flow. Commun. ACM 19(5): 236-243 (1976) (Biba) Biba, K. Tech report – hard to find (TE) Boebert, W. E. and Kain, R. Y. 1985. A practical alternative to hierarchical integrity policies. In Proceedings of the 8th National Computer Security Conference (Gaithersburg, Md.). (DTE) Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M. and Haghighat, S. A. 1995. Practical Domain and Type Enforcement for Unix. In Proceedings of the IEEE Symposium on Security and Privacy. (Myers) Myers, A.C., Liskov, B. Complete, Safe Information Flow with Decntralized Labels. 1998. In Proceedings of the IEEE Symposium on Security and Privacy. (RBAC) Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein, and Charles E. Youman. Role-based access control models. IEEE Computer, 29(2):38-47, February 1996. (Information Flow) J. Goguen and J. Meseguer, Security Policies and security models, In Proceedings of the 1982 IEEE Symposium on Research in Security and Privacy, IEEE Computer Security Press, 1982. (ASL) S. Jajodia, P. Samarati, and V.S. Subrahmanian, A Logical Language for Expressing Authorizations, Proc. of the IEEE Symposium on Security and Privacy, Oakland, CA, 1997. (OASIS) Jean Bacon, Ken Moody, Walt Yao: A model of OASIS role-based access control and its support for active security. ACM Trans. Inf. Syst. Secur. 5(4): 492-540 (2002) (HRU) M.A. Harrison, M.L. Ruzzo, and J.D. Ullman. Protection in operating systems. Communications of the ACM, 19(8):461--471, 1976. (Take-Grant) Jones, A. K., Lipton, R. J., and Snyder, L., "A Linear Time Algorithm for Deciding Security," Proc. 17th Annual Symp. on Found. of Comp. Sci., 1976. References