Announcements Access control John Mitchell u Homework Due today. Next assignment out next week u Graders If interested in working as grader, send email to Anupam u Projects Combine some of the project ideas Two more project assignments Next one posted next week References u Viega and McGraw Chapter 8, Access Control u Windows http://www.microsoft.com/ u CFS, EFS Use Google to find web sites Access control in operating systems u Assumption System knows who the user is User has entered a name and password, or other info Access requests pass through gatekeeper Global property; OS must be designed so that this is true User process Reference monitor? Resource Secure OS: also apply controls to kernel processes 1
Access control decision Access control matrix [Lampson] Given: user and request for privilege Decide: whether to grant request File 1 File 2 File 3 File n User 1 User process filename /? Resource User 2 User 3 Terminology: privilege = resource, rightò User m Roles u Role = set of users Administrator, PowerUser, User, Guest Assign permissions to roles; each user gets permission u Role hierarchy Partial order of roles Administrator Each role gets PowerUser permissions of roles below List only new permissions User given to each role Guest Resource, Right groups u Like roles, but for resources or rights If user has right r for resource, and r>s, then user has right s If user has access to directory, user has access to every file in directory u Big problem with access control Complex mechanisms require complex input Difficult to configure and maintain Roles, other organizing ideas try to simplify problem 2
Unix file security u Each file has owner and group u Permissions set by owner setid Read,, execute Owner, group, other rwx rwx rwx Represented by vector of four octal values ownr grp othr Unix file security u File can set effective user id (EUID) u Only owner, root can change permissions This privilege cannot be delegated or shared u Umask Permissions to be denied when new file is created Question u Suppose owner has fewer privileges What happens? User gets access? User does not? u Prioritized resolution of differences if user = owner then owner permission else if user in group then group permission else other permission Effective user id (EUID) u Each process has two Ids Real user ID same as the user ID of parent (unless changed) used to determine which user started the process Effective user ID from set user ID bit on the file being executed determines what permissions the process has file access and port binding u Real group ID, effective group ID, used similarly 3
Setid Bits Compare to stack inspection u 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 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 u Careful with Setuid! Can do anything that owner of file is allowed to do Be sure not to Take action for untrusted user Return secret data to untrusted user A 1 B 1 C 1 Programming interface Setuid programming u Can, modify permissions from program u Setreuid(x_uid, y_uid) Set real and effective uid to given values Can be used to set EUID back to UID after done with operation that needed setuid If program not owned by root, both x_uid and y_uid must be UID or EUID u Note: lots of things are possible if root; no middle ground between user and root u Dan talked about this before u Be Careful! Root can do anything; don t get tricked Principle of least privilege change EUID when root privileges no longer needed u Setuid scripts This is a bad idea Historically, race conditions Begin executing setuid program; change contents of program before it loads and is executed 4
Unix summary u We re all very used to this So probably seems pretty good We overlook ways it might be better u Good things Some protection from most users Flexible enough to make things possible u Main bad thing Too tempting to use root privileges No way to assume some root privileges without all root privileges Access control in Windows (NTFS) u Basic functionality similar to Unix Specify access for groups and users Read, modify, change owner, delete u Some additional concepts Tokens Security attributes u Generally More flexibility than Unix Can define new permissions Can give some but not all administrator privileges Sample permission options u SID Identity (replaces UID) SID revision number 48bit authority value variable number of Relative Identifiers (RIDs), for uniqueness Users, groups, computers, domains, domain members all have SIDs Permission Inheritance u Static permission inheritance (Win NT) Initially, subfolders inherit permissions of folder Folder, subfolder changed independently Replace Permissions on Subdirectories command Eliminates any differences in permissions u Dynamic permission inheritance (Win 2000) Child inherits parent permission, remains linked Parent changes are inherited, except explicit settings Inherited and explicitlyset permissions may conflict Resolution rules Positive permissions are additive Negative permission (deny access) takes priority 5
Tokens u Security Reference Monitor uses tokens to identify the security context of a process or th u Security context privileges, accounts, and groups associated with the process or th u Impersonation token th uses temporarily to adopt a different security context, usually of another user Token fields u Token Source Description of the entity that created the token u Token Identifier Locally unique identifier u Expiration Time Present but unused in NT since NT 3.1 Security Descriptor Example access request u Information associated with an object who can perform what actions on the object u Several 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) users, groups, System Access Control List (SACL) system logs,.. Access token Security descriptor User: Mark Group1: Administrators Group2: Writers Revision Number Control flags Owner SID Group SID DACL Pointer SACL Pointer Deny Writers Read, Write Allow Mark Read, Write Access request: Action: denied User Mark requests permission Descriptor denies permission to group Reference Monitor denies request 6
Impersonation Tokens (setuid?) u Process uses security attributes of another Client passes impersonation token to server u Client specifies impersonation level of server Anonymous Token has no information about the client Identification server obtain the SIDs of client and client's privileges, but server cannot impersonate the client Impersonation server identify and impersonate the client Delegation lets server impersonate client on local, remote systems Encrypted File Systems (EFS, CFS) u Store files in encrypted form Key management: user s key decrypts file Useful protection if someone steals disk u Windows EFS User marks a file for encryption Unique file encryption key is created Key is encrypted, can be stored on smart card u Unix CFS [Matt Blaze] Transparent use Local NFS server running on "loopback" interface Key protected by passphrase Capabilities u Operating system concept of the future and always will be u Examples Dennis and van Horn, MIT PDP1 Timesharing Hydra, StarOS, Intel iapx 432, Amoeba, Eros, u Reference Henry Levy, Capabilitybased Computer Systems http://www.cs.washington.edu/homes/levy/capabook/index.html ACL vs Capabilities u Access control list Associate list with each object Check user/group against list Relies on authentication: need to know user u 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 7
ACL vs Capabilities ACL vs Capabilities User U Process P User U Process Q User U Process R Capabilty c,d Process P Capabilty c Process Q Capabilty c Process R u Delegation Cap: Process can pass capability at run time ACL:???? u 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 what data is capability If capability is used for multiple resources, have to revoke all or none Other details Rolebased access control (RBAC) Example: The Three Musketeers u Main ideas Users are associated with roles Roles are associated with permissions A user has a permission only if the user has an authorized role which is associated with that permission User/Permission Association Athos palace uniform Aramis Porthos weapons D'Artagnan u Source: John Barkley, NIST RBAC Project 8
Example: The Three Musketeers Quantifying RBAC Advantage RBAC Athos Porthos Aramis D'Artagnan Musketeer palace uniform weapons u For each job position, let: U = Number of individuals in job position P = Number of permissions required for position (U + P) < (U P) fi RBAC Advantage u For all job positions, Sum up advantage for each position S i (U i + P i ) < S (U i P i ) Example: D Artagnon becomes a Musketeer NIST RBAC Model D'Artagnan D'Artagnan Musketeer palace uniform palace uniform weapons u Role Hierarchies, e.g, teller inherits employee u Conflict of Interest Constraints Static Separation of Duty: user cannot be authorized for both roles, e.g., teller and auditor Dynamic Separation of Duty: user cannot act simultaneously in both roles, e.g., teller and account holder u Role Cardinality: maximum number of users authorized for role, e.g., branch manager weapons 9
Distributed Access Control Single signon systems e.g. Securant, Netegrity, Oblix u Resources distributed across network How do we control use of resources? How to identify users, establish privileges? u Centralized solutions Authenticate users Use policy determine privileges u Distributed solutions Need to combine policies from different sites Resource monitor must authenticate requests user name password Rules Authentication LAN Data Application Data u Limitations Centralized access point is a performance and administration bottleneck Developed for single enterprise; not extensible to multiple organizations User name / password authentication does not support nonrepudiation Distributed Access Control Certificate Authority Policies Credentials Credentials Policies Deduction Engine Deduction Engine Resource Monitors 10