Trent Jaeger -- Background Security Fundamentals: Models

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 Trent Jaeger L4 -based systems: , Lava, JavaOS, SawMill Security policy: graphical access control, constraint models January 12, 2004 – 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.

Why are we still talking about access Access Control control?

Determine whether a principal can perform An access control policy is a specification for an a requested operation on a target object access decision function Principal: user, process, etc. The policy aims to achieve – Permit the principal’s intended function (availability) Operation: read, write, etc. – Ensure security properties are met (integrity, confidentiality) Object: file, tuple, etc. Limit to “Least Privilege,” Protect system integrity, Prevent Lampson defined the familiar access matrix unauthorized leakage, etc. and its two interpretations ACLs and Also known as ‘constraints’ capabilities [Lampson70] – Enable administration of a changeable system (simplicity)

“Simple” example Access Control is Hard Because

Prof Alice manages access to course objects Access control requirements are domain-specific – Assign access to individual (principal: Bob) – Generic approaches over-generalize – Assign access to aggregate (course-students) – Associate access to relation (students(course)) Access control requirements can change – Assign students to project groups (student(course, project, group)) – Anyone could be an administrator Prof Alice wants certain guarantees The Safety Problem [HRU76] – Students cannot modify objects written by Prof Alice – Can only know what is leaked right now – Students cannot read/modify objects of other groups Prof Alice must be able to maintain access policy Access is fail-safe, but Constraints are not – Ensure that individual rights do not violate guarantees – And constraints must restrict all future states – However, exceptions are possible – students may distribute their results from previous assignments for an exam

1 Compare to Other CS Problems Reference Monitor Model

Entry Points Processor design System – Hard, but can get some smart people together to construct Interface one, fixed, testable design Access Hook Network protocol design Authorize Request? – TCP: A small number of control parameters necessary to manage all reasonable options, within a layered architecture – Constraints, such as DDoS, are ad hoc Security-sensitive Access Operation Access Monitor Hook Software design Hook Policy – Specific goals in mind to achieve function, constraints are ad hoc Security-sensitive Security-sensitive Operation Operation Yes/No

Reference Monitor Components Access Control Models

Interface Basic Access Matrix – Where to make access control decisions (mediation) – , ACL, various capability systems – Which access control decisions to make (authorization) Aggregated Access Matrix – Linux Security Modules interface – TE, RBAC, groups and attributes, parameterized Plus Domain Transitions Decision function – DTE, SELinux, Java – Compute decision based on request and policy Lattice Access Control Models – E.g., SELinux, LIDS, DTE, etc. modules – Bell-LaPadula, Biba, Denning Policy – our focus today Predicate Models – How to represent access control policy – ASL, OASIS, domain-specific models, many others – Main mechanism issue – find mechanism to enable verification Safety Models that policy achieves function and meets security guarantees – Take-grant, Schematic Protection Model, Typed Access Matrix

Need for Aggregate Models (RBAC) Type Enforcement [BoebertKain84]

Practical ease of specification – Abstraction for users, permissions, constraints, administration Permission Natural access control aggregations – based on Assignment Object organizational roles User – As new employees join, their permission assignments are Subject Type Can determined by their job Type Type Access Object Type Object – Permission assignment is largely static User (Subject) To Perform Operations (Object) Central control and maintenance of access rights On Objects Flexible enough to enforce User – least privilege, separation of duties, etc. Object

2 Group and Attributes Role-based Access Control

User-Role Assignment Perm-Role Assignment Permission Role Assignment Object Perm Object User User

User Group Has Users in Role Can User Access To Objects Access Objects Using Attribute Object Permissions Perm Object User Group With the Attribute User

User Object User Perm Object

Role vs. Types Data Structures Role-based Access Control Model

RBAC Users: U – U: set of users Permissions: P – P: set of permissions Roles: R Type Enforcement – E: set of subjects or objects Assignments: User-role, perm-role, role-role – Permission Assignment Sessions: S ST: set of subject types Function: user(S), roles(S) OT: set of object types O: set of operations Constraints:

RBAC Family of Models Hierarchies and Constraints

Role hierarchy RBAC0 contains all but hierarchies and constraints – Problem: does organizational hierarchy correspond to a RBAC1 contains RBAC0 and hierarchies permission inheritance hierarchy? – Problem: do organizational roles make sense for building RBAC2 contains RBAC0 and constraints hierarchies? RBAC3 contains all Constraints – Problem: constraints apply to all states, so they require a predicate The RBAC family idea has always been more a calculus in general NIST initiative – Problem: Only certain types of constraints can effectively be administered? Mutual exclusion, separation of duty, cardinality, The RBAC families are present in the NIST RBAC etc. standard [NIST2001] with slight modifications: Conflicts – RBAC0, RBAC1 (options), RBAC3 (SSD) , RBAC3 (DSD) – May find other concepts useful for resolving conflicts between constraints and hierarchies/assignments

3 Administration Does RBAC Achieve Its Goals?

Discretionary Access Control Practical ease of specification – Clear base model – need more help for constraints, admin – Users (typically object owner) can decide Natural access control aggregations – based on permission assignments organizational roles Mandatory Access Control – In some cases, but not clear that organizational roles help with permission assignment – particularly with inheritance – System administrator decides on permission assignments Central control and maintenance of access rights – Central view is a selling feature of products, but a single Flexible Administrative Management view of all can be complex (layering?) – Access control models can be used to express Flexible enough to enforce – Flexible access control expression, but difficult to determine administrative privileges if we enforce our security goals (constraints)

RBAC Products Safety Problem [HRU76]

Determine if an unauthorized permission is leaked given SUN Solaris – An initial set of permissions and Sybase SQL Server – An access control system, mainly administrative operations For a traditional approach, the safety problem is undecidable BMC INCONTROL for Security Management – Access matrix model with multi-operational commands – Main culprit is create – create object/subject with own rights Systor Security Administration Manager – Prove reduction of a Turing machine to the multi-operational access matrix system Tivoli TME Security Management Result led to – Safe, but limited models: take-grant, schematic protection model, Computer Associates Protect IT typed access matrix model – Further support for models in which the constraints are implicit in the Siemens rbacDirX model – e.g., lattice models – Check safety on each policy change – constraint approach of RBAC

Lattice Access Control Models Security Levels and Policies

Read/writeRead/write Subjects and Objects have security levels and Dominance L:1 optional categories 1 > 2 > 3 Read Write Confidentiality Policy (e.g., Bell-LaPadula) – Simple property: may read only if the subject’s security level BLP Operations dominates the object’s security level (read-down) Biba Operations L:2 – *-property: may write only if the subject’s security level is Read Write dominated by the object’s security level (write-up) – Tranquility property: may not change the security level of an object concurrent to its use L:3 Integrity Policy – Biba is the dual of BLP for integrity

4 Purpose of BLP and Biba Denning’s Lattice Model

BLP Formalizes information flow models – Prevent Trojan horses from leaking information to lower security – FM = {N, P,SC,,} levels Shows that the information flow model instances form a lattice – Mandatory access control and implicit constraints – {SC, } is a partial ordered set, Biba – SC is finite, – Prevent low integrity information flows to higher integrity processes – SC has a lower bound, – E.g., code, configuration, user requests, buffer overflows – and is a lub operator Categories/Compartments for separation within levels Implicit and explicit information flows Safety is implicit in the model Semantics for verifying that a configuration is secure – No additional constraints are needed to express security Static and dynamic binding considered guarantees Biba and BLP are among the simplest models of this type

Implicit and explicit flows Semantics

Explicit Program is secure if: – Direct transfer to b from a (e.g., b = a) – Explicit flow from S is secure Implicit – Explicit flow of all statements in a sequence are – Where value of b may depend on value of a indirectly (e.g., if a = 0, then b = c) secure (e.g., S1; S2) Model covers all programs – Conditional c:S1, …, Sm is secure if: – Statement S The explicit flows of all statements S1, …, Sm are – Sequence S1, S2 secure – Conditional c: S1, …, Sm The implicit flows between c and the objects in Si are Implicit flows only occur in conditionals secure

Static and Dynamic Binding Model Examination

Static binding Static binding – BLP and Biba check security property at runtime – Security class of an object is fixed Guarantees security of all implicit and explicit flows – This is the case for BLP and Biba If a, then b = c means that a b, so SC(a) must be dominated by SC(b) in BLP – This is the case for most system models Otherwise, information leakage Dynamic binding – Data Mark Machine Security class depends on location in program – Security class of an object can change Combine with condition class on entering condition – For b = a, then the security class of b is b a Data flow captured because c b is checked in condition and b a is checked outside and is transitive – Rare approach Does not hold for dynamic binding

5 Model Examination Verification Example

Certification Mechanism d = PS TS – Static check eliminates covert channels e = MS – Limits e d X Language defect could miss a check (buffer overflow) d = TS Hardware malfunction MS PS e = MS Approach e d OK – Verify information flow w/i a statement S = S1 S2 = MS c S, c dominated by MS d = a + b; a b d; d must dominate – Set statement security level S = d NS – Statement sequence S = S1S2 – must be able to flow to greatest lower bound – Verify c d1, …, dn for implicit flow

Dynamic Binding Lattice Model Features

Definition Safe policies w/o constraints – May change the security class of an object that removes it from – Bell-LaPadula is consistent with military security policy view – could leak covertly! – Biba is not consistent with any practical integrity policy Dynamic Data Mark Problem: Downgraders/Upgraders – Combine program class with actual data flow class – Static binding mechanism doesn’t work – Changing the security label of an object requires sanitization paper example shows that dynamic class updating does not account Remove secrets for confidentiality downgrade for implicit flows Remove low integrity data for integrity upgrade Local object solution ensures correct classification, but seems – Sanitization is ad hoc functionally limiting Static analysis to insert classification statements to cover implicit flows – Sanitizer must be of trusted (more stringent requirement than simply being at the higher security class) High Water Mark – Class is raised to prevent leakage a b whenever b = a Lattice model effectiveness is limited by the number of – Similar flaw to Dynamic Data Mark – and similar fix downgraders

Recent Information Flow Policies Decentralized Labels

Information flow in programming languages Labels have owners and readers – Andrew Myers (Cornell), Steve Zdancewic (U Penn), Barbara – L = {o1: r1, r2; o2: r2, r3} Liskov (MIT) – Effective readers of L {r2} because only it can read from o1 and o2 Decentralized Label Model Static binding – Flow policies of principals implemented by labeled data – Label of a value is forgotten when assigned to a variable – System guarantees to enforce all policies simultaneously Relabeling semantics – A new label contains the owners of the old, but fewer readers – Declassification enables remove of restrictions “where appropriate” – determined by programmer Declassification semantics – Enables static checking – An authority for an owner can add the owner or readers of the owner Advantage: assume programmer is trusted to describe security Label join/meet semantics policies – Join (e.g., multiply 2 numbers) Union owners and intersect readers – Programmers can prevent Trojan horse leakage in downgrade – Meet (dual of join): Intersect owners and union readers?

6 Other Models References

(Ref monitor) Irvine, C.E., The Reference Monitor Concept as a (RBAC) Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein, Unifying and Charles E. Youman. Role-based access control models. Principle in Computer Security Education, Proceeding IFIP IEEE Computer, 29(2):38-47, February 1996. Plus Domain Transitions TC11 WC 11.8 First World Conference on Information Security Education , Kista, Sweden, June 1999, pp 27--37 (Information Flow) J. Goguen and J. Meseguer, Security Policies and security models, In Proceedings of the 1982 IEEE – DTE, SELinux, Java (BLP) Bell-LaPadula: MITRE tech report – hard to find Symposium on Research in Security and Privacy, IEEE Computer Security Press, 1982.

(Denning) Dorothy E. Denning: A Lattice Model of Secure Information Flow. Commun. ACM 19(5): 236-243 (1976) (ASL) S. Jajodia, P. Samarati, and .S. Subrahmanian, A Predicate Models Logical Language for Expressing Authorizations, Proc. of the IEEE Symposium on Security and Privacy, Oakland, CA, 1997. (Biba) Biba, K. Tech report – hard to find

(OASIS) Jean Bacon, Ken Moody, Walt Yao: A model of OASIS – ASL, OASIS, domain-specific models, many (TE) Boebert, W. E. and Kain, R. Y. 1985. A practical alternative role-based access control and its support for active security. to hierarchical integrity policies. In Proceedings of the 8th ACM Trans. Inf. Syst. Secur. 5(4): 492-540 (2002) National Computer Security Conference (Gaithersburg, Md.).

others (HRU) M.A. Harrison, M.L. Ruzzo, and J.D. Ullman. Protection (DTE) Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M. in operating systems. Communications of the ACM, 19(8):461-- and Haghighat, S. A. 1995. Practical Domain and Type 471, 1976. Enforcement for Unix. In Proceedings of the IEEE Symposium on Security and Privacy. Safety Models (Take-Grant) Jones, A. K., Lipton, R. J., and Snyder, L., "A Linear Time Algorithm for Deciding Security," Proc. 17th Annual (Myers) Myers, A.C., Liskov, B. Complete, Safe Information Symp. on Found. of Comp. Sci., 1976. Flow with Decntralized Labels. 1998. In Proceedings of the – Take-grant, Schematic Protection Model, Typed IEEE Symposium on Security and Privacy. Access Matrix

7