Operating System Security Discretionary Seong-je Cho ( 조성제 ) (sjcho at dankook.ac.kr) Fall 2018 Computer Security & Operating Systems Lab, DKU - 1-524870, F 18
Discretionary (DAC) Allows the owner of the resource to specify which subjects can access which resources Access control is at the discretion of the owner Object owner has the authority to control access of the object A system that enables the object owner to specify set of Users with access to a set of objects DAC models enforce access control based on user identities, object ownership and permission delegation The owner of an object may delegate the permission of the object to another user -2-
DAC models Discretionary: users can be given the ability of passing on their privileges to other users, where granting and revocation of privileges is regulated by an administrative policy. DAC model = Access Matrix model = Matrix model DAC can be implemented through Lists (ACLs) or Capability Lists -3-
DAC model = Access Matrix model Access Matrix = Matrix (an abstract model) is a table of subjects and objects indicating what actions individual subjects can take upon individual objects. Each row of this table is associated with a subject (or principal) Each column of the table is associated with an object each entry in the matrix indicates the access rights of a particular subject for a particular object An empty cell means that no access rights are granted. Access Matrix is implemented primarily in three ways List (ACL): bound to an object Capability List : bound to a subject Authorization Table Three columns: subjects, access rights, objects Generally used in DBMS systems -4-
Access Matrix -5-
ACLs vs. Capability Lists For each object, an ACL lists users and their permitted access rights A capability ticket specifies authorized objects and operations for a particular user -6-
ACLs vs. Capability lists List (ACL): Object-centered approach Capability List: Subject-centered approach ACLs /etc/passwd /usr/bin/ /u/roberto/ /admin/ root: r,w mike: r roberto: r backup: r root: r,w,x mike: r,x roberto: r,x backup: r,x root: r,w,x roberto: r,w,x backup: r,x root: r,w,x backup: r,x -7-
Capability Lists It defines, for each subject s, the list of the objects for which s has nonempty access control rights, together with the specific rights for each such object. root /etc/passwd: r,w,x; /usr/bin: r,w,x; /u/roberto: r,w,x; /admin/: r,w,x roberto /usr/passwd: r; /usr/bin: r; /u/roberto: r,w,x mike /usr/passwd: r; /usr/bin: r,x backup /etc/passwd: r,x; /usr/bin: r,x; /u/roberto: r,x; /admin/: r,x -8-
ACLs vs. Capabilities Capabilities Quick to check like a ticket so scale well ACLs slow to check - scalability problem if expressiveness exploited e.g. negatives and exceptions allowed if there are many subjects and large groups generalization? multidomain operation? names outside domain of registration? In a distributed system many services are not part of privileged OSs. Anonymous knowledge of names not needed may generalize to multiple domains. anonymity may be wanted by some applications for privacy reasons -9-
ACLs vs Capability List Immediate to check the authorization holding on an object with ACLs. (subject?) Immediate to determine the privileges of a subject with Capability lists. (object?) Distributed system, authenticate once, access various servers choose which one? Limited number of groups of users, small bit vectors, authorization specified by owner. Which one? -10-
Table 4.1 Authorization Table for Files in Figure 4.3 A relational DB can implement an authorization table of this type. 11
Figure 4.4 Extended Matrix Suppose that the entry α* exists in A[S0, X]. This means that S0 has access right α to subject X and, because of the presence of the copy flag, can transfer this right, with or without copy flag, to another subject. 12
Figure 4.5 Function 1. A subject S0 issues a request of type α for object X. 2. The request causes the system (the operating system or an access control interface module of some sort) to generate a message of the form (S0, α, X) to the controller for X. 3. The controller interrogates the access matrix A to determine if α is in A[S0, X]. If so, the access is allowed; if not, the access is denied and a protection violation occurs. The violation should trigger a warning and appropriate action. 13
Table 4.2 System Commands Rule R3 permits S0 to delete any access right from any matrix entry in a row for which S0 controls the subject and for any matrix entry in a column for which S0 owns the object. 14
Protection Domains set of objects together with access rights to those objects more flexibility when associating capabilities with protection domains In terms of the access matrix, a row defines a protection domain User can spawn processes with a subset of the access rights of the user Association between a process and a domain can be static or dynamic In user mode, certain areas of memory are protected from user s use and certain instructions may not be executed In kernel mode, privileged instructions may be executed and protected areas of memory may be accessed 15
Protection Domains A protection domain is a set of (object, access rights) pairs, where each pair specifies for a given object exactly what operations can be carried out By associating a protection domain with each request, we can cut down on redundant information in access control lists One approach to using protection domains is to construct groups of users -16-
UNIX/Linux DAC is implemented as Lists (ACLs)
UNIX Challenges More about protection than security Implicitly assumes non-malicious user and trusted system processes Discretionary (DAC) User or their processes may update permission assignments Each program has all user s rights Must trust their processes to be non-malicious A system that uses DAC allows the owner of the resource to specify which subjects can access which resources. Access control is at the discretion of the owner. File permission assignments Assignment based on what is necessary for things to work All your processes have all your rights System services have full access User invoke setuid (root) procs that have all rights Must trust system processes 18
UNIX Protection State Subjects Users Groups Processes make accesses on behalf of users belonging to particular groups Objects UID (Real UID, Effective UID, Saved UID), GID Effective UID determines access Files Regular files, Device (character or block), Socket, FIFO, Link Files are stored as inodes Directories Operations Read Write Execute -19-
UNIX File UNIX files are administered using inodes (index nodes) control structures (inodes) with key information needed for a particular file several file names may be associated with a single inode an active inode is associated with exactly one file file attributes, permissions and control information are sorted in the inode on the disk there is an inode table, or inode list, that contains the inodes of all the files in the file system when a file is opened its inode is brought into main memory and stored in a memory resident inode table directories are structured in a hierarchical tree may contain files and/or other directories contains file names plus pointers to associated inodes 20
UNIX File unique UID member of a primary group identified by a GID belongs to a specific group 12 protection bits specify read, write, and execute permission for the owner of the file, members of the group and all other users SetUID, SetGID, Sticky bit the UID, GID, and protection bits are part of the file s inode Superuser is exempt from usual access control restrictions -21-
Changing permissions Change permissions of a file chmod chmod 644 file -- owner can read/write, group, others can read only chmod u+x file -- adds execute permission for owner Change owner of a file chown chown new_owner file Change group of a file chgrp chgrp new_group file -22-
Lists (ACLs) in UNIX modern UNIX systems support ACLs FreeBSD, OpenBSD, Linux, Solaris FreeBSD setfacl command assigns a list of UNIX user IDs and groups any number of users and groups can be associated with a file read, write, execute protection bits a file does not need to have an ACL includes an additional protection bit that indicates whether the file has an extended ACL when a process requests access to a file system object two steps are performed: step 1 selects the most appropriate ACL ACL entries are looked at in the following order: owner named users (owning or named) groups others step 2 checks if the matching entry contains sufficient permissions 23
Linux command: setfacl / getfacl It sets ACLs of files and directories setfacl [-bkndrlpvh] [{-m -x} acl_spec] [{-M -X} acl_file] file Granting an additional user read access setfacl -m u:lisa:r file Revoking write access from all groups and all named users (using the effective rights mask) setfacl -m m::rx file Removing a named group entry from a file's ACL setfacl -x g:staff file Options --set and --set-file: They set the ACL of a file or a directory. The previous ACL is replaced -m (--modify) and M (--modify-file) -x (--remove) and X (--remove-file) -d, --default - : If the file name parameter is a single dash, setfacl reads a list of files from standard input Copying the ACL of one file to another getfacl file1 setfacl --set-file=- file2 Copying the access ACL into the Default ACL getfacl -a dir setfacl -d -M- dir -24-
ACLs in UNIX FreeBSD and most UNIX implementations that support extended ACLs use the following strategy (e.g., Figure 4.6b): 1. The owner class and other class entries in the 9-bit permission field have the same meaning as in the minimal ACL case. 2. The group class entry specifies the permissions for the owner group for this file. These permissions represent the maximum permissions that can be assigned to named users or named groups, other than the owning user. In this latter role, the group class entry functions as a mask. 3. Additional named users and named groups may be associated with the file, each with a 3-bit permission field. The permissions listed for a named user or named group are compared to the mask field. Any permission for the named user or named group that is not present in the mask field is disallowed. 25
Linux command: getfacl Get file access control lists getfacl [-drlpvh] file 1: # file: somedir/ 2: # owner: lisa 3: # group: staff 4: user::rwx 5: user:joe:rwx #effective:r-x 6: group::rwx #effective:r-x 7: group:cool:r-x 8: mask:r-x 9: other:r-x 10: default:user::rwx 11: default:user:joe:rwx #effective:r-x 12: default:group::r-x 13: default:mask:r-x 14: default:other:--- Extended ACLs Line 4,6 and 9 are the base ACL entries Lines 5 and 7 are named user and named group entries. Line 8 is the effective rights mask. This entry limits the effective rights granted to all groups and to named users. (The file owner and others permissions are not affected by the effective rights mask; all other entries are.) Lines 10--14 display the default ACL associated with this directory. Directories may have a default ACL. Regular files never have a default ACL. -26-
getfacl & setfacl -27-
ACLs in Linux chacl command change the ACL of a file or directory Minimum ACL chacl u::rwx,g::r-x,o::r-- file An ACL that specifies a user or group other than the file's owner or owner's group, must contain a mask entry: chacl u::rwx,g::r-x,o::r--,u:bob:r--,m::r-x file1 file2 To set the default and access ACLs on newdir to be the same as on olddir, you could type: chacl -b `chacl -l olddir \ sed -e 's/.*\[//' -e 's#/# #' -e 's/]$//'` newdir when a process requests access to a file system object two steps are performed: step 1 selects the most appropriate ACL ACL entries are looked at in the following order: owner named users (owning or named) groups others step 2 checks if the matching entry contains sufficient permissions -28-
UNIX File set user ID (SetUID) set group ID (SetGID) system temporarily uses rights of the file owner / group in addition to the real user s rights when making access control decisions enables privileged programs to access files / resources not generally accessible sticky bit when applied to a directory it specifies that only the owner of any file in the directory can rename, move, or delete that file superuser is exempt from usual access control restrictions has system-wide access 29
SetUID, SetGID, Sticky bit $ id uid=504(sjcho) gid=504(sjcho) groups=504(sjcho) context=user_u:system_r:unconfined_t $ ls -l /usr/bin/passwd -rwsr-xr-x 1 root root 22984 Jan 7 2007 /usr/bin/passwd $ ls -l /etc/passwd -rw-r--r-- 1 root root 2133 Mar 29 17:08 /etc/passwd $ ls -l / drwxrwxrwt 11 root root 24576 Mar 29 18:14 tmp drwxr-xr-x 14 root root 4096 Mar 4 14:02 usr -30-
Real and Effective UIDs (RUID, EUID) Most of the time, the EUID of a process is just the same as the real ones. However, the EUID of a process can differ from the RUID when the process invokes a setuid program. Assume you're logging into your normal user account, which has a user ID of 500. Now you invoke a setuid root application. Because it's setuid root, the OS will set the EUID of the process to that of the root user (0). The RUID, however, remains unchanged. -31-
UID transitions: setuid Domain transitions -32-
Advantages of DAC Users can self manage access privileges. The burden of security administrators is significantly reduced, as resource users and administrators jointly manage permission. Per-user granularity for individual access decisions as well as coarse-grained access for groups are supported. It is easy to change privileges. Supporting new privileges is easy. -33-
Limitation of DAC DAC has trouble to ensure consistency if there is a global policy Global policy: DAC let users to decide the access control policies on their data, regardless of whether those policies are consistent with the global policies. Therefore, if there is a global policy, DAC has trouble to ensure consistency. Information flow: information can be copied from one object to another, so access to a copy is possible even if the owner of the original does not provide access to the original copy. -34-
Limitation of DAC Information flow: It is not appropriate for multilayered systems where information flow is restricted. (That is, DACs are inadequate for enforcing Information flow policies) It provides no constraint on copying information from one object to another So access to a copy is possible even if the owner of the original does not provide access to the original copy. This has been a major concern for military. -35-
Limitation of DAC: Malicious software: DAC policies can be easily changed by owner, so a malicious program (e.g., a downloaded untrustworthy program) running by the owner can change DAC policies on behalf of the owner. Flawed software: Similarly to the previous item, flawed software can be instructed by attackers to change its DAC policies. -36-
Disadvantages of DAC There is no mechanism for restricting rights other than revoking the privilege. It becomes quickly complicated and difficult to maintain access rights as the number of users and resources increases. It is difficult to judge the reasonable rights for a user or group. Inconsistencies in policies are possible due to individual delegation of permission. Access may be given to users that are unknown to the owner of the object. This is possible since the user granted authority by the owner can give away access to other users. -37-
Take Away UNIX security originally aimed at protection in multiuser systems DAC over files UNIX DAC security model cannot express security requirements Lots of rights accessible by default Means for limiting rights are impractical The use of UNIX mechanisms has evolved over time Resulting in vulnerabilities -38-
Summary access control prevent unauthorized users from gaining access to resources prevent legitimate users from accessing resources in an unauthorized manner enable legitimate users to access resources in an authorized manner subjects, objects, access rights authentication, authorization, audit discretionary access controls (DAC) controls access based on user identity mandatory access control (MAC) controls access based on security labels role-based access control (RBAC) controls access based on roles 39
chroot Create a domain in which a process is confined int chroot (const char *path); // chroot ( /car/myroot ); Process can only read/write within file system subtree Applies to all descendant processes Can carry file descriptors in chroot jail chroot vulnerability Unfortunately, chroot can trick its own system define a passwd file at <newroot>/etc/passwd run su su thinks that this is the real passwd file gives root access Use mknod to create device file to access physical memory Setup requires great care Never run chroot process as root Must not be able to get root privileges No control by chrooted process (user) of contents in jail Be careful about descriptors, open sockets, IPC that may be available -40-
Device File Vulnerabilities Devices are represented as files /dev/tty terminal /dev/mem -- physical memory /dev/kmem -- virtual memory /dev/mouse -- mouse Create using mknod (only accessible by root) Can bypass access control by getting access to memory /dev/kmem or /dev/mem used to be world accessible Can get access to user inputs /dev/tty is world readable -- see password, set keys mesg n -- prevents write access to current terminal -41-
Link Vulnerabilities Add new path to an inode Multiple names for a single inode Run ln -s /etc/passwd file trusted_dump file < *passwd-entry* To overwrite /etc/passwd Programs have to be aware of which files they are using open(file, O_NOFOLLOW, mode) Prevents open from following a link Also, problems with access, then open File name to inode mapping causes problems -42-
/tmp Vulnerability creat(pathname, mode) O_EXCL flag if file already exists this is an error Potential attack Create file in shared space (/tmp) Give it a filename used by a higher authority service Make sure that service has permission to the file If creat is used without O_EXCL, then can share the file with the higher authority process -43-