Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
- 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-