Security Fundamentals: Models Trent Jaeger
Total Page：16
File Type：pdf, Size：1020Kb
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 microkernel-based systems: L4Linux, 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) – UNIX, 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: C 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