Outline Access Control and Operating u Access Control u Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks u OS Policies u Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • Common Criteria • Unix • Windows 2000 – File system, Setuid certification • Windows u Some Limitations – File system, Tokens, EFS • Information flow • SE Linux • Covert channels – Role-based – Domain type enforcement Access control Access control matrix [Lampson] uCommon Assumption • 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 – Global property; OS must be designed so that this is true User 2 write write write - - Reference 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 uAccess control list (ACL) File 1 File 2 … uOperating system concept • Store column of matrix User 1 read write - • “… of the future and always will be …” with the resource User 2 write write - uExamples uCapability User 3 - - read • Dennis and van Horn, MIT PDP-1 Timesharing • Allow user to hold a … • Hydra, StarOS, Intel iAPX 432, Amoeba, Eros, … “ticket” for each resource User m read write write • Roughly: store row of matrix with the user uReference • Henry Levy, Capability-based Computer Systems http://www.cs.washington.edu/homes/levy/capabook/ Access control lists are widely used, often with groups Some aspects of capability concept are used in Kerberos, … 1 Roles (also called Groups) Groups for resources, rights uRole = set of users uPermission = áright, resourceñ • Administrator, PowerUser, User, Guest uGroup related resources • Assign permissions to roles; each user gets permission uHierarchy for rights or resources uRole hierarchy • If user has right r, and r>s, then user has right s • Partial order of roles Administrator • If user has read access to directory, user has read • Each role gets access to every file in directory PowerUser permissions of roles below • List only new permissions User uBig problem in access control given to each role • Complex mechanisms require complex input Guest • Difficult to configure and maintain • Roles, other organizing ideas try to simplify problem Multi-level Security Concepts Military security policy uMilitary security policy uSensitivity levels uCompartments – Classification involves sensitivity levels, compartments – Do not let classified information leak to unclassified files Satellite data uGroup individuals and resources Afghanistan • Use some form of hierarchy to organize policy Middle East Israel uOther concepts Top Secret • Separation of duty Secret • Chinese Wall Policy Confidential Restricted Unclassified Military security policy Commercial version uClassification of personnel and data Product specifications • Class = árank, compartmentñ Discontinued uDominance relation In production OEM • D1 £ D2 iff rank1 £ rank2 Internal and compartment1 Í compartment2 Proprietary • Example: áRestricted, Israelñ £ áSecret, Middle Eastñ Public uApplies to • Subjects – users or processes • Objects – documents or resources 2 Bell-LaPadula Confidentiality Model Picture: Confidentiality uWhen is it OK to release information? Read below, write above Read above, write below uTwo Properties (with silly names) • Simple security property Proprietary Proprietary – A subject S may read object O only if C(O) £ C(S) • *-Property – A subject S with read access to O may write object P only if C(O) £ C(P) S S uIn words, • You may only read below your classification and Public Public only write above your classification Biba Integrity Model Picture: Integrity uRules that preserve integrity of information Read above, write below Read below, write above uTwo 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 – A subject S with read access to O may write object P only S S if C(O) ³ C(P) (Only move info from O to P if O is more trusted than P) uIn words, Public Public • You may only write below your classification and only read above your classification Problem: Models are contradictory Other policy concepts uBell-LaPadula Confidentiality uSeparation of duty • Read down, write up • If amount is over $10,000, check is only valid if uBiba Integrity signed by two authorized people • Read up, write down • Two people must be different • Policy involves role membership and ¹ uWant both confidentiality and integrity • Only way to satisfy both models is only allow read uChinese Wall Policy and write at same classification • 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 In reality: Bell-LaPadula used more than Biba model – No lawyer can work for opposite sides in any case Example: Common Criteria • Permission depends on use of other permissions 3 Example OS Mechanisms Multics uMultics uOperating System uUnix • Designed 1964-1967 uWindows – MIT Project MAC, Bell Labs, GE • At peak, ~100 Multics sites (briefly) uSE Linux • Last system, Canadian Department of Defense, Nova Scotia, shut down October, 2000 u Extensive Security Mechanisms • Influenced many subsequent systems http://www.multicians.org/security.html Multics time period Multics Innovations uTimesharing was new concept uSegmented, Virtual memory • Serve Boston area with one 386-based PC • Hardware translates virtual address to real address uHigh-level language implementation • Written in PL/1, only small part in assembly lang uShared memory multiprocessor • Multiple CPUs share same physical memory uRelational database • Multics Relational Data Store (MRDS) in 1978 uSecurity • Designed to be secure from the beginning • First B2 security rating (1980s), only one for years Multics Access Model Unix file security uRing structure uEach file has owner and group • A ring is a domain in which a process executes uPermissions set by owner setid • Numbered 0, 1, 2, … ; Kernel is ring 0 • Read, write, execute - rwx rwx rwx • Graduated privileges • Owner, group, other – Processes at ring i have privileges of every ring j > i • Represented by vector of ownr grp othr uSegments four octal values • Each data area or procedure is called a segment uOnly owner, root can change permissions • Segment protection áb1, b2, b3ñ with b1 £ b2 £ b3 • This privilege cannot be delegated or shared – Process/data can be accessed from rings b1 … b2 – A process from rings b2 … b3 can only call segment at uSetid bits – Discuss in a few slides restricted entry points 4 Question Effective user id (EUID) uOwner can have fewer privileges than other uEach process has three Ids (+ more under Linux) • What happens? • Real user ID (RUID) – User gets access? – same as the user ID of parent (unless changed) – User does not? – used to determine which user started the process • Effective user ID (EUID) – from set user ID bit on the file being executed, or sys call uPrioritized resolution of differences – determines the permissions for process if user = owner then owner permission • file access and port binding else if user in group then group permission • Saved user ID (SUID) else other permission – So previous EUID can be restored uReal group ID, effective group ID, used similarly Process Operations and IDs Setid bits on executable Unix file uRoot uThree setid bits • ID=0 for superuser root; can access any file • Setuid – set EUID of process to ID of file owner uFork and Exec • Setgid – set EGID of process to GID of file • Inherit three IDs, except exec of file with setuid bit • Sticky – Off: if user has write permission on directory, can rename uSetuid system calls or remove files, even if not owner • seteuid(newid) can set EUID to – On: only file owner, directory owner, and root can – Real ID or saved ID, regardless of current EUID rename or remove file in the directory – Any ID, if EUID=0 uDetails are actually more complicated • Several different calls: setuid, seteuid, setreuid Example Compare to stack inspection Owner 18 RUID 25 SetUID uCareful with Setuid ! • Can do anything that A 1 …; program owner of file is …; allowed to do B 1 exec( ); • Be sure not to Owner 18 -rw-r--r-- – Take action for …; RUID 25 untrusted user C 1 file read/write …; EUID 18 – Return secret data to i=getruid() untrusted user Owner 25 setuid(i); -rw-r--r-- …; read/write RUID 25 Note: anything possible if root; no middle file …; EUID 25 ground between user and root 5 Setuid programming Unix summary uWe talked about this before … uWe’re all very used to this … uBe Careful! • So probably seems pretty good • Root can do anything; don’ t get tricked • We overlook ways it might be better • Principle of least privilege – change EUID when uGood things root privileges no longer needed • Some protection from most users uSetuid scripts • Flexible enough to make things possible • This is a bad idea uMain bad thing • Historically, race conditions • Too tempting to use root privileges – Begin executing setuid program; change contents of • No way to assume some root privileges without all program before it loads and is executed root privileges Access control in Windows (NTFS) Sample permission options uBasic functionality similar to Unix uSID • Specify access for groups and users • Identity (replaces UID) – Read,