- 1 - 524870, F’19

Seong-je Cho (조성제)

(sjcho at dankook.ac.kr)

Fall 2019

Computer Security & Operating Systems Lab, DKU

Operating System Security

Discretionary Access Control

Access Control

Discretionary Access Control (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-

Access Control

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 = Access Control Matrix model

DAC can be implemented through Access Control Lists (ACLs) or Capability Lists

-3-

Access Control

DAC model = Access Matrix model

Access Matrix = Access Control 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

− Access Control 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 Control

Access Matrix

-5-

Access Control

ACLs vs. Capability Lists

-6-

For each object, an ACL lists users and their permitted access rights

A capability ticket specifies authorized objects and operations for a particular user

Access Control

ACLs vs. Capability lists

Access Control List (ACL): Object-centered approach

Capability List: Subject-centered approach

ACLs

-7-

/etc/passwd /usr/bin/ /u/roberto/ /admin/

root: r,w,xbackup: r,x

root: r,w,xroberto: r,w,xbackup: r,x

root: r,w,xmike: r,xroberto: r,xbackup: r,x

root: r,wmike: rroberto: rbackup: r

Access Control

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.

-8-

/etc/passwd: r,w,x; /usr/bin: r,w,x; /u/roberto: r,w,x; /admin/: r,w,xroot

/usr/passwd: r; /usr/bin: r,xmike

/usr/passwd: r; /usr/bin: r;/u/roberto: r,w,xroberto

backup/etc/passwd: r,x; /usr/bin: r,x; /u/roberto: r,x; /admin/: r,x

Access Control

ACLs vs. Capabilities

ACLs

slow to check - scalabilityproblem

● if expressiveness exploited e.g. negatives and exceptions allowed

● if there are many subjects and large groups

● generalization? multi-domain operation? names outside domain of registration?

In a distributed system many services are not part of privileged OSs.

-9-

Capabilities

Quick to check – like a ticket – so scale well

Anonymous – knowledge of names not needed – may generalize to multiple domains.

● anonymity may be wanted by some applications for privacy reasons

Access Control

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 Access Control 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

Access Control 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.2Access Control

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

Access Control

UID transitions via setuid prog Domain transitions

-16-

setuid program

Access Control

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 ACLs

One approach to using protection domains is to construct groups of users

-17-

DAC can be implemented asAccess Control Lists (ACLs)

UNIX/Linux Access Control

Access Control

DAC

More about protection than security● Implicitly assumes non-malicious user and trusted system processes

Discretionary Access Control (DAC)● User or their processes may update permission assignments

− Each program has all user’s rights

− Must trust their processes to be non-malicious

● Owner specifies which subjects can access which resources.

− Owner of a resource can designate permissions

− Access control is at the discretion of the owner.

● Owner of object sets access rights

− Regular users can adjust the policy

− Subjects has total control over objects

19

Access Control

UNIX Challenges

DAC

● Object owner has full power

− Complete trust in users

− Decisions are based only on UID and object ownerships

• Decision made based on identity of requestor and access rules

− Impossible to control information flow

File permission assignments

● All your processes have all your rights

Traditional access controls do not clearly separate the privileges of users and applications acting on the users behalf, increasing the damage that can be caused by application exploits.

System services have full access

● User invoke setuid (root) procs that have all rights

− Must trust system processes

-20-

Access Control

UNIX Protection State

Subjects

● Users

● Groups

● Processes make accesses on behalf of users belonging to particular groups

− UID (Real UID, Effective UID, Saved UID), GID

− Effective UID determines access to objects

Objects

● Files – Regular files, Device (character or block), Socket, FIFO, Link

− Files are managed with inodes

● Directories

Operations

● Read

● Write

● Execute

-21-

$ id

# chmod 4755 prog1

# chown root prog2

# chgrp root prog3

Access Control

UNIX File Access Control

-22-

12 protection bits

read, write, and execute permission for owner, group, and all other users

SetUID, SetGID, Sticky bit

“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

Access Control

UNIX File Access Control

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

− UID, GID, and protection bits are part of the file’s 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

-23-

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

24

Access Control

Linux command: setfacl / getfacl

-25-

It sets ACLs of files and directories

setfacl [-bkndRLPvh] [{-m|-x} acl_spec] [{-M|-X} acl_file] 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

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

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

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.

26

Access Control

Linux command: getfacl

-27-

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.

Access Control

getfacl & setfacl

-28-

Access Control

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

-29-

Access Control

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.

-30-

Access Control

Problem with 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.

● It is not appropriate for multilayered systems where information flow is restricted.

− 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.

-31-

Access Control

Problem with DAC

Information flow:

● DACs are inadequate for enforcing Information flow policies

− They provide no constraint on copying information from one object to another

● Example: Consider Alice, Bob, and Eve.

− Alice has a file X that she wants Bob to read, but not Eve.

− Alice authorizes Bob via the following Access Control Matrix

− Bob can subvert Alice’s discretion by copying X into Y.

• Bob has write privileges, and Eve has read privileges for Y.

− This case is a simplistic version of what can be much more pathological… The Trojan Horse…

-32-

Access Control

DAC and Trojan Horses

-33-

What if Bob isn’t bad… Eve could still read X by convincing Bob to use a program carrying a Trojan Horse (Troy)

Consider the new access control matrix:

● Eve has created Troy and given it to Bob, who has execute privileges

● Troy inherits Bob’s read privileges to X, and write privileges to a file Y (perhaps public)

● Eve has read privileges to file Y

Trojan Horses perform normal “claimed” operations, but also participates in subversive activities

Solution:Impose Mandatory Access Controls

(MAC) that cannot be bypassed.

Access Control

DAC and Trojan Horses

-34-

Access Control

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.

-35-

Access Control

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.

● Discretionary means anyone with access can propagate information

-36-

Access Control

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

-37-

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

38

Access Control

SetUID, SetGID, Sticky bit

$ iduid=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

-39-

Access Control

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-

Access Control

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-