Outline (may not finish in one lecture) Access Control and Operating Access Control Concepts Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks OS Mechanisms Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • Common Criteria • Amoeba • Windows 2000 – Distributed, capabilities certification • Unix Some Limitations – File system, Setuid • Information flow • Windows • Covert channels – File system, Tokens, EFS • SE Linux – Role-based, Domain type enforcement Access control Access control matrix [Lampson] Common Assumption Objects • System knows who the user is File 1 File 2 File 3 … File n – User has entered a name and password, or other info • Access requests pass through gatekeeper User 1 read write - - read – OS must be designed monitor cannot be bypassed User 2 write write write - - Reference Subjects monitor User 3 - - - read read User process ? Resource … User m read write read write read Decide whether user can apply operation to resource Two implementation concepts Capabilities Access control list (ACL) File 1 File 2 … Operating system concept • “… of the future and always will be …” • Store column of matrix User 1 read write - Examples with the resource User 2 write write - • Dennis and van Horn, MIT PDP-1 Timesharing Capability User 3 - - read • Hydra, StarOS, Intel iAPX 432, Eros, … • User holds a “ticket” for … • Amoeba: distributed, unforgeable tickets each resource User m read write write • Two variations References – store row of matrix with user – unforgeable ticket in user space • Henry Levy, Capability-based Computer Systems http://www.cs.washington.edu/homes/levy/capabook/ Access control lists are widely used, often with groups • Tanenbaum, Amoeba papers Some aspects of capability concept are used in Kerberos, … 1 ACL vs Capabilities ACL vs Capabilities Access control list • Associate list with each object User U Capabilty c,d • Check user/group against list Process P Process P • Relies on authentication: need to know user Capabilities User U Capabilty c • Capability is unforgeable ticket Process Q Process Q – Random bit sequence, or managed by OS – Can be passed from one process to another User U Capabilty c • Reference monitor checks ticket Process R Process R – Does not need to know identify of user/process ACL vs Capabilities Roles (also called Groups) Delegation Role = set of users • Cap: Process can pass capability at run time • Administrator, PowerUser, User, Guest • ACL: ???? • Assign permissions to roles; each user gets permission Revocation Role hierarchy • ACL: Remove user or group from list • Partial order of roles Administrator • Cap: Try to get capability back from process? • Each role gets PowerUser – Possible in some systems if appropriate bookkeeping permissions of roles below • OS knows what data is capability • List only new permissions User • If capability is used for multiple resources, have to given to each role revoke all or none … Guest • Other details … Groups for resources, rights Multi-Level Security (MLS) Concepts Permission = 〈right, resource〉 Military security policy Permission hierarchies – Classification involves sensitivity levels, compartments – Do not let classified information leak to unclassified files • If user has right r, and r>s, then user has right s • If user has read access to directory, user has read Group individuals and resources access to every file in directory • Use some form of hierarchy to organize policy Other policy concepts Big problem in access control • Separation of duty • Complex mechanisms require complex input • “Chinese Wall” Policy • Difficult to configure and maintain • Roles, other organizing ideas try to simplify problem 2 Military security policy Military security policy Sensitivity levels Compartments Classification of personnel and data • Class = 〈rank, compartment〉 Satellite data Dominance relation Afghanistan • D D iff rank rank Middle East 1 ≤ 2 1 ≤ 2 Israel and compartment1 ⊆ compartment2 Top Secret Secret • Example: 〈Restricted, Israel〉≤〈Secret, Middle East〉 Confidential Applies to Restricted • Subjects – users or processes Unclassified • Objects – documents or resources Commercial version Bell-LaPadula Confidentiality Model Product specifications When is it OK to release information? Discontinued Two Properties (with silly names) In production • Simple security property OEM – A subject S may read object O only if C(O) ≤ C(S) Internal • *-Property Proprietary – A subject S with read access to O may write object P only if C(O) ≤ C(P) Public In words, • You may only read below your classification and only write above your classification Picture: Confidentiality Biba Integrity Model Read below, write above Read above, write below Rules that preserve integrity of information Two Properties (with silly names) • Simple integrity property Proprietary Proprietary – A subject S may write object O only if C(S) ≥ C(O) (Only trust S to modify O if S has higher rank …) • *-Property S S – A subject S with read access to O may write object P only if C(O) ≥ C(P) (Only move info from O to P if O is more trusted than P) Public Public In words, • You may only write below your classification and only read above your classification 3 Picture: Integrity Problem: Models are contradictory Read above, write below Read below, write above Bell-LaPadula Confidentiality • Read down, write up Biba Integrity Proprietary Proprietary • Read up, write down Want both confidentiality and integrity S S • May use Bell-LaPadula for some classification of personnel and data, Biba for another – Otherwise, only way to satisfy both models is only allow read and write at same classification Public Public In reality: Bell-LaPadula used more than Biba model Example: Common Criteria Other policy concepts Example OS Mechanisms Separation of duty Multics • If amount is over $10,000, check is only valid if Amoeba signed by two authorized people Unix • Two people must be different • Policy involves role membership and ≠ Windows Chinese Wall Policy SE Linux (briefly) • Lawyers L1, L2 in Firm F are experts in banking • If bank B1 sues bank B2, – L1 and L2 can each work for either B1 or B2 – No lawyer can work for opposite sides in any case • Permission depends on use of other permissions These policies cannot be represented using access matrix Multics Multics time period Operating System Timesharing was new concept F.J. Corbato • Designed 1964-1967 • Serve Boston area with one 386-based PC – MIT Project MAC, Bell Labs, GE • At peak, ~100 Multics sites • Last system, Canadian Department of Defense, Nova Scotia, shut down October, 2000 Extensive Security Mechanisms • Influenced many subsequent systems http://www.multicians.org/security.html E.I. Organick, The Multics System: An Examination of Its Structure, MIT Press, 1972 4 Multics Innovations Multics Access Model Segmented, Virtual memory Ring structure • Hardware translates virtual address to real address • A ring is a domain in which a process executes High-level language implementation • Numbered 0, 1, 2, … ; Kernel is ring 0 • Written in PL/1, only small part in assembly lang • Graduated privileges Shared memory multiprocessor – Processes at ring i have privileges of every ring j > i • Multiple CPUs share same physical memory Segments • Each data area or procedure is called a segment Relational database • Segment protection 〈b1, b2, b3〉 with b1 ≤ b2 ≤ b3 • Multics Relational Data Store (MRDS) in 1978 – Process/data can be accessed from rings b1 … b2 Security – A process from rings b2 … b3 can only call segment at • Designed to be secure from the beginning restricted entry points • First B2 security rating (1980s), only one for years Multics process Amoeba Server port Obj # Rights Check field Multiple segments Distributed system • Segments are dynamically linked • Multiple processors, connected by network • Linking process uses file system to find segment • Process on A can start a new process on B • A segment may be shared by several processes • Location of processes designed to be transparent Multiple rings • Procedure, data segments each in specific ring Capability-based system • Access depends on two mechanisms • Each object resides on server – Per-Segment Access Control • Invoke operation through message to server • File author specifies the users that have access to it – Send message with capability and parameters – Concentric Rings of Protection • Call or read/write segments in outer rings – Sever uses object # to indentify object • To access inner ring, go through a “gatekeeper” – Sever checks rights field to see if operation is allowed Interprocess communication through “channels” – Check field prevents processes from forging capabilities Capabilities Server port Obj # Rights Check field Unix file security Owner capability Each file has owner and group • When server creates object, returns owner cap. Permissions set by owner setid – All rights bits are set to 1 (= allow operation) • Read, write, execute – Check field contains 48-bit rand number stored by server - rwxrwx rwx Derived capability • Owner, group, other ownr grp othr • Owner can set some rights bits to 0 • Represented by vector of • Calculate new check field four octal values – XOR rights field with random number from check field Only owner, root can change permissions – Apply one-way function to calculate new check field • This privilege cannot be delegated or shared • Server can verify rights and check filed – Without owner capability, cannot forge derived