Introduction to Information Security 0368-3065, Spring 2016 Lecture 9: Secure Architecture Principles, Access Control Avishai Wool Slides credit: Eran Tromer, John Mitchell, Stanford Max Krohn, MIT Ian Goldberg and Urs Hengartner, University of Waterloo

Secure Architecture Principles: Isolation and Least Privilege

Basic idea: Isolation A Seaman's Pocket-Book, 1943 (public domain)

Principles of Secure Design Compartmentalization Isolation Principle of least privilege Defense in depth Use more than one security mechanism Secure the weakest link Fail securely Keep it simple

Principle of Least Privilege Ability to access or modify a resource Principle of Least Privilege A system module should only have the minimal privileges needed for intended purposes Requires compartmentalization and isolation Separate the system into independent modules Limit interaction between modules

Example: Android process isolation Android application sandbox Isolation: Each application runs with its own UID in own VM Provides memory protection Communication protected using Unix domain sockets Only ping, zygote (spawn another process) run as root Interaction: reference monitor checks permissions on inter-component communication Least Privilege: Applications announces permission Whitelist model – user grants access Questions asked at install time, to reduce user interruption

Access control Concepts

? Access control Assumptions Resource User process System knows who the user is Authentication via name and password, other credential Access requests pass through gatekeeper (reference monitor) System must not allow monitor to be bypassed Reference monitor Resource ? User process access request policy

Access control matrix [Lampson] Subjects users, processes Objects files, sockets, resources File 1 File 2 File 3 … File n User 1 read write - User 2 User 3 User m

Two implementation concepts Access control list (ACL) Store column of matrix with the resource Capability User holds a “ticket” for each resource Two variations store row of matrix with user, under OS control unforgeable ticket in user space File 1 File 2 … User 1 read write - User 2 User 3 User m Read Access control lists are widely used, often with groups Some aspects of capability concept are used in many systems

ACL vs Capabilities Access control list Capabilities Associate list with each object Check user/group against list Relies on authentication: need to know user Capabilities Capability is unforgeable ticket Random bit sequence, or managed by OS Can be passed from one process to another Reference monitor checks ticket Does not need to know identify of user/process

ACL vs Capabilities User U Process P Process P Capabilty c,d,e User U Process Q Process Q Capabilty c,e User U Process R Capabilty c Process R

ACL vs Capabilities Delegation Revocation Cap: Process can pass capability at run time ACL: Try to get owner to add permission to list? More common: let other process act under current user Revocation ACL: Remove user or group from list Cap: Try to get capability back from process? Possible in some systems if appropriate bookkeeping OS knows which data is capability If capability is used for multiple resources, have to revoke all or none … Indirection: capability points to pointer to resource If C  P  R, then revoke capability C by setting P=0

Roles (also called Groups) Role = set of users Administrator, PowerUser, User, Guest Assign permissions to roles; each user gets permission Role hierarchy Partial order of roles Each role gets permissions of roles below List only new permissions given to each role Administrator PowerUser User Guest

Role-Based Access Control Individuals Roles Resources engineering Server 1 Server 2 marketing Server 3 human res Advantage: users change more frequently than roles

Access control Unix

Unix access control File has access control list (ACL) Grants permission to user ids Owner, group, other Process has user id Inherit from creating process Process can change id Restricted set of options Special “root” id Bypass access control restrictions File 1 File 2 … User 1 read write - User 2 User 3 User m Read

Unix file access control list Each file has owner and group Permissions set by owner Read, write, execute Owner, group, other Represented by vector of four octal values 0755 (rwxr-xr-x)  public directory or executable 0644 (rw-r--r--)  public file 0600 (rw-------)  private file Only owner, root can change permissions This privilege cannot be delegated or shared Setid bits – Discuss in a few slides setid - rwx rwx rwx ownr grp othr

Owner can have fewer privileges than other Question Owner can have fewer privileges than other What happens? Owner gets access? Owner does not? Prioritized resolution of differences if user = owner then owner permission else if user in group then group permission else other permission

Process effective user id (EUID) Each process has three Ids (+ more under Linux) Real user ID (RUID) same as the user ID of parent (unless changed) 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 determines the permissions for process file access and port binding Saved user ID (SUID) So previous EUID can be restored Real group ID, effective group ID, used similarly

Process Operations and IDs Root ID=0 for superuser root; can access any file Fork and Exec Inherit three IDs, except exec of file with setuid bit Setuid system calls seteuid(newid) can set EUID to Real ID or saved ID, regardless of current EUID Any ID, if EUID=0 Details are actually more complicated Several different calls: setuid, seteuid, setreuid

setid bits on executable Unix file Three setid bits Setuid – set EUID of process to ID of file owner Setgid – set EGID of process to GID of file Sticky Off: if user has write permission on directory, can rename or remove files, even if not owner On: only file owner, directory owner, and root can rename or remove file in the directory

setuid example Owner 18 RUID 25 SetUID …; program exec( ); Owner 18 i=getruid() setuid(i); -rw-r--r-- RUID 25 file read/write EUID 18 Owner 25 RUID 25 -rw-r--r-- read/write EUID 25 file

setuid programming Be Careful with Setuid 0 ! Root can do anything; don’t get tricked Principle of least privilege – change EUID when root privileges no longer needed

Access Control Windows

Access control in Windows (since NTFS) Some basic functionality similar to Unix Specify access for groups and users Read, modify, change owner, delete Some additional concepts Tokens Security attributes Generally More flexibility than Unix Can define new permissions Can give some but not all administrator privileges

Identify subject using SID Security ID (SID) Identity (replaces UID) SID revision number 48-bit authority value variable number of Relative Identifiers (RIDs), for uniqueness Users, groups, computers, domains, domain members all have SIDs

Each process has set of tokens Security context Privileges, accounts, and groups associated with the process or thread Presented as set of tokens Reference Monitor Uses tokens to identify the security context of a process or thread Impersonation token Used temporarily to adopt a different security context, usually of another user

Each object has security descriptor Security descriptor, associated with an object, specifies who can perform what actions on the object Fields: Header Descriptor revision number Control flags, attributes of the descriptor E.g., memory layout of the descriptor SID of the object's owner SID of the primary group of the object Two attached optional lists: Discretionary Access Control List (DACL) controls access by users, groups, … System Access Control List (SACL) controls logging of access to system logs

Example access request User: Mark Access token Access request: write Action: denied Group1: Administrators Group2: Redhaired Revision Number Control flags User Mark requests write permission Descriptor denies permission to group Reference Monitor denies request Owner SID Group SID DACL Pointer Security descriptor SACL Pointer Deny ACE1 Redhaired Order of ACEs in ACL matters. Windows reads ACL until permission is Granted or Denied, then stops. Read, Write ACE2 (Access Control Entry Allow Mark Read, Write

Impersonation Tokens (compare to setuid) Process adopts security attributes of another Client passes impersonation token to service Client specifies impersonation level of service Anonymous The service can impersonate the client but the impersonation token does not contain any information about the client. Identification The service can get the identity of the client and use this information in its own security mechanism, but it cannot impersonate the client. Impersonation The service can impersonate the client (on local computers). Delegation The service can impersonate the client on local and remote computers.

Access control policies

Multi-Level Security (MLS) Concepts Military security policy Classification involves sensitivity levels, compartments Do not let classified information leak to unclassified files Group individuals and resources Use some form of hierarchy to organize policy Other policy concepts Separation of duty “Chinese Wall” Policy (managing conflicts of interests)

Military security policy Compartments Sensitivity levels Satellite data Micronesia Middle East Israel בצה"ל סודי ביותר סודי שמור מוגבל בלמ"ס Top Secret Secret Confidential Restricted Unclassified

Example: military security policy Classification of personnel and data Class = rank, compartment Dominance relation C1  C2 iff rank1  rank2 and compartment1  compartment2 Example: Restricted, Israel  Secret, Middle East Applies to Subjects – users or processes Objects – documents or resources

Example: commercial policy Product specifications Discontinued In production OEM Internal Proprietary Public

Generalizing: lattices A dominance relationship that is transitive and antisymmetric defines a lattice For two levels a and b, maybe neither a ≥ b nor b ≥ a However, for every a and b, there is a lowest upper bound u for which u ≥ a and u ≥ b, and a greatest lower bound l for which a ≥ l and b ≥ l There are also two elements U and L that dominate/are dominated by all levels In next slide’s example, U = (“Top Secret”, {“Middle East”, “Micronesia”}) L = (“Unclassified”, )‏

Example Lattice (“Top Secret”, {“Middle East”, “Micronesia”}), (“Secret”, {“Micronesia”}) (“Unclassified”, )‏

Bell-LaPadula Confidentiality Model 1976, Multics When is it OK to release information? Two properties No read up A subject S may read object O only if C(O)  C(S) No write down A subject S with read access to O may write to object P only if C(O)  C(P) You may only read below your classification and write above your classification

Bell-LaPadula Confidentiality Model “No read up” – intuitive “No write down” – forbid high-classified reader to copy and reduce classification Special “Trusted user” allowed to write-down Mandatory Access Control: protect even against malicious software / users / trojan horses who try to violate policy. In contrast: Linux & Windows use Discretionary Access Control: owners can set permissions

Picture: Confidentiality Read below, write above S Public Proprietary Read above, write below Proprietary S Public

Bell-LaPadula Gaps Focus on Confidentiality, not much else Assigning classification to all files and user – hard. Classification of data data changes over time Data tends to migrate up: a trusted user has to continually "downgrade" it. Bruce Schneier: "Data sometimes have a higher classification in aggregate than each datum does individually”

Biba Integrity Model 1975 Goal: preserve integrity of information (dual to confidentiality) Two properties No write up A subject S may write object O only if C(S)  C(O) (Only trust S to modify O if S has higher rank …) No read down 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) You may only write below your classification and read above your classification

Picture: Integrity S S Read above, write below Public Proprietary Read below, write above Proprietary S Public

Biba Integrity Model 1975 High level information is most reliable  readable by all Lowest level information is least reliable  only low-level users can read it

Problems with MLS Covert channels Declassification (when OK to violate strict policy?) Composability (e.g, one-time-pad) Aggregation (many “low” facts may enable deduction of “high” information) Overclassification (label creep) Incompatibilies (e.g., upgraded files “disappear”) Polyinstantiation (maintaining consistency when different users have different view of the data, and perhaps even see “cover stories”)

These policies cannot be represented using access matrix Other policy concepts Separation of duty If amount is over $10,000, check is only valid if signed by two authorized people Two people must be different Policy involves role membership and  Chinese Wall Policy Lawyers L1, L2 in same firm If company C1 sues C2, L1 and L2 can each work for either C1 or C2 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

Policies: further reading Anderson, Stajano, Lee, Security Policies https://www.cl.cam.ac.uk/~rja14/Papers/security-policies.pdf Levy, Capability-Based Computer Systems http://www.cs.washington.edu/homes/levy/capabook

Information Flow Control

Information Flow Control An information flow policy describes authorized paths along which information can flow For example, Bell-La Padula describes a lattice-based information flow policy

Program-level IFC Input and output variables of program each have a (lattice-based) security classification S() associated with them For each program statement, compiler verifies whether information flow is secure For example, x = y + z is secure only if S(x) ≥ lub(S(y), S(z)), where lub() is lowest upper bound Program is secure if each of its statements is secure

Implicit information flow Conditional branches carry information about the condition: secret bool a; public bool b; … b = a; if (a) { b = 1; } else { b = 0; } Possible solution: assign label to program counter and include it in every operation. (Too conservative!)

IFC: Implementation approaches Language-based IFC (JIF & others) Compile-time tracking for Java, Haskell Static analysis Provable security Label creep (false positives) Dynamic analysis Language / bytecode / machine code Tainting False positives, false negatives Performance Hybrid solutions OS-based DIFC (Asbestos, HiStar, Flume) Run-time tracking enforced by a trusted kernel Works with any language, compiled or scripting, closed or open

Difficulties with Information Flow Control Label creep Examples: Branches Logically-false flows “Doesn’t really matter” Declassification Example: encryption Catching all flows Exceptions (math division by 0, null pointer, out of bounds access…) Signals Covert channels