Access Control and Operating System

Access Control and Operating System

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

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    12 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us