Operating System Security Access control for memory Access control for files, BLP model Access control in Linux file systems (read on your own)
Hw1 grades out this Friday Announcement Travel: out of town for a meeting next Tuesday Attack/Defense presentation Rachael Stempfley, Peter Price, Alex Van Brunt Move to Thursday (we are going to have two presentations)? Our guest speaker and TA will be here Topic: Deception-Based Defenses May or may not have quiz (not graded) 2
What does Operating System do Manages all the resource in a computer (including processor, memory, i/o devices) Provides an interface between the hardware and application software
Trusted Computer System Evalua3on Criteria (TCSEC) is a US Department of Defense (DoD) standard that sets basic requirements for assessing the effec:veness of computer security controls built into a computer system. The TCSEC was used to evaluate, classify and select computer systems being considered for the processing, storage and retrieval of sensi:ve or classified informa:on. The Orange Book From wikipedia.com
Tagged architecture for memory protection In i960mx the memory subsystem was made 33-bits wide for a 32-bit word and a "tag" bit to indicate protected memory (popular in 1990s for embedded systems) IBM System/38 from Wikipedia.com Available in August 1979
Tagged Architecture To have fine-grained data protection Protect some values but not all To be able to modify the protection E.g., first allow write, then read-only Base/bound registers are all-or-nothing Tagged architecture: Every word of memory has one or more extra bits to identify the access rights to that word Access bits set only by privileged instructions Bits are tested when an instruction accesses that location Can have a few more tag bits for different classes of data, etc Used in IBM system/38 & Burroughs; compatibility issues with other OS codel From Pfleeger & Pfleeger
Advanced security models for the confidentiality and integrity of files
Slides credit to Ethan L. Miller and Scott A. Brandt ACCESS CONTROL
Protection Domains Three protection domains Each lists objects with permitted operations Domains can share objects & permissions Objects can have different permissions in different domains There need be no overlap between object permissions in different domains How can this arrangement be specified more formally? File1 [R] File2 [RW] File3 [R] File4 [RWX] File5 [RW] Printer [W] File3 [W] Screen1 [W] Mouse [R] Domain 1 Domain 2 Domain 3 9
Access Matrix Domain File1 File2 File3 File4 File5 Printer1 Mouse 1 Read Read Write 2 Read Read Write Execute Read Write Write 3 Write Write Read Each domain has a row in the matrix Each object has a column in the matrix Entry for <object,column> has the permissions Who s allowed to modify the protection matrix? What changes can they make? How is this implemented efficiently? 10
Representing the protection matrix Need to find an efficient representation of the protection matrix (also called the access matrix) Most entries in the matrix are empty! Compress the matrix by: Associating permissions with each object à access control list Associating permissions with each domain à capabilities How is this done, and what are the tradeoffs?
Each object has a list List has Protection domain o User name o Group of users o Other Access rights o Read o Write o Execute (?) o Others? Access control lists File1 elm: <R,W> znm: <R> root: <R,W,X> File2 elm: <R,X> uber: <R,W> root: <R,W> all: <R> No entry for domain => no rights for that domain Operating system checks permissions when access is needed 12
Access control lists in the real world Unix file system Access list for each file has exactly three domains on it o User (owner) o Group o Others Rights: read, write, execute AFS (Andrew File System) for client/server systems Access lists only apply to directories Files inherit rights from the directory are in Access list may have many entries on it with possible rights: o read, write, lock (for files in the directory) o lookup, insert, delete (for the directories themselves), o administer (ability to add or remove rights from the ACL) 13
Capabilities Each process has a capability list List has one entry per object the process can access Object name Object permissions Objects not listed are not accessible How are these secured? Kept in kernel Cryptographically secured Process A File1: <R,W> File2: <R> File3: <R,W,X> Process B File2: <R,W> File4: <R,W,X> File7: <W> File9: <R,W> 14
Protecting the access matrix: summary OS must ensure that the access matrix isn t modified (or even accessed) in an unauthorized way Access control lists Reading or modifying the ACL is a system call OS makes sure the desired operation is allowed Capability lists Similar to ACLs: reading and modification done by OS Can be handed to processes and verified cryptographically later on May be better for widely distributed systems where capabilities can t be centrally checked 15
SECURITY MODELS 16
Multi-Level Security (MLS) Military security policy is based on protec:ng classified informa:on Hierarchy of Sensi:vity ranks
Compartments and Sensitivity ranks project Least Sensi:ve Compartments may not be hierarchical 18
Need-to-know Rule In Military Security Policy <rank, compartments> class or classification of information A clearance is an indication that a person is trusted to access data up to some rank E.g., secret clearance Dominance relation between subjects and objects s dominates o (denoted by s o) s has a need to know all the compartments for which o is classified For subject s and object o, s o if and only if rank s rank o and compartments o compartments s e.g.,top secret > secret A subject s can read an object o if s dominates o
Bell-LaPadula confidentiality model (BLP) Biba integrity model
Bell-LaPadula Model read down/write up Security levels arranged in linear ordering Top Secret: highest Secret Confidential Unclassified: lowest Levels consist of security clearance L(s) Objects have security classification L(o) security level subject object Top Secret Tamara Personnel Files Secret Samuel E-Mail Files Confidential Claire Activity Logs Unclassified Alice Telephone Lists Tamara can read all files Claire cannot read Personnel or E-Mail Files Alice can only read Telephone Lists
Reading/Writing Information Information flows up, not down Reads up disallowed, reads down allowed Subject s can read object o iff, L(o) L(s) and s has permission to read o (aka simple security condition) No reads up rule Writes up allowed, writes down disallowed *-Property Subject s can write object o iff L(s) L(o) and s has permission to write o. (aka *-property) No writes down rule
Bell-La Padula in Process Management Processes, objects have security level Simple security property Process at level k can only read objects at levels k or lower * property Process at level k can only write objects at levels k or higher These prevent information from leaking from higher levels to lower levels 4 3 2 1 5 E 6 3 C 4 D A writes 4 B 2 1 A 23
Basic Security Theorem in BLP model If a system is ini:ally in a secure state, and every transi:on of the system sa:sfies the simple security condi:on, and the *-property, then every state of the system is secure
Biba multilevel integrity model Principles to guarantee integrity of data Simple integrity principle A process can write only objects at its security level or lower No way to plant fake information at a higher level The integrity * property A process can read only objects at its security level or higher Prevent someone from getting information from above and planting it at their level Biba is in direct conflict with Bell-La Padula Difficult to implement both at the same time! 25
Biba Integrity Model Bell-La Padula model (read-down/write-up) Biba (read-up/write-down) dual of BLP model Subject cannot corrupt data in a higher level Subject cannot be corrupted by data with a lower level 1. s S can read o O iff i(s) i(o) 2. s S can write to o O iff i(o) i(s) 3. s 1 S can execute s 2 S iff i(s 2 ) i(s 1 ) i is integrity level
Key Points MAC vs. DAC (mandatory access control vs. discretionary access control) Confidentiality models restrict flow of information Bell-LaPadula models multilevel security Cornerstone of much work in computer security BLP model is generally believed to be very restrictive Integrity policies deal with trust As trust is hard to quantify, hard to evaluate completely Look for assumptions and trusted users to find possible weak points Clark-Wilson (will discuss later in the course) focuses on separation of duty and transactions
Computer Virus Theory and Experiments by Fred Cohen J. of Virology 1987 Virus Detec:on is Undecidable That is, they (USC) told me everything I needed to know all the way down to the bolom.''
How to prevent computer viruses from spreading? l In order for users of a system to be able to share informa:on, there must be a path through which informa:on can flow from one user to another. BLP model (write-up, read-down) allows virus to spread across mul:ple security levels
Isola:onism If there is no sharing, then no dissemination of information across information boundaries Thus, a virus cannot spread outside a single partition. - However, isolationism is unacceptable if we wish to benefit from the work of others.
l Partition models and flow models Partition model -- partitions of a system into isolated subsystems - Resulting in closed subsets - e.g., Biba integrity model (read-up/write-down) - Biba: no user at a given integrity level can read an object of lower integrity or write an object of higher integrity. l Flow model no par::on, but limit the extend over which a virus can spread - flow distance policy keeps track of the distance (number of sharings) over which data has flowed - e.g., with transi:vity limited to a distance of 1, it is safe to share informa:on with any user you trust without having to worry about whether that user has incorrectly trusted another user. - e.g., user A can only be allowed to access informa:on wrilen by users (B and C) or (B and D), but not informa:on wrilen by B, C, or D alone. Useful to enforce cer:fica:on of informa:on by B, before C or D can pass it to A.
Experiments with computer viruses l First test on VAX 11/750 system - the name virus was thought of by Len Adleman. - Virus prepends program 'vd' l Second test on Univac 1108. - On a Bell-LaPadula based system Adleman - demonstrated the ability to cross user boundaries and move from a given security level to a higher security level - no system flaws involved in this activity - (supporting the Biba model will help with the file integrity and isolation)