A Survey of Access Control Policies Amanda Crowell
What is Access Control? Policies and mechanisms that determine how data and resources can be accessed on a system.
The Players Subjects Objects Semi-objects Action Component Examples: users, processes, thread, program Items that can be created, modified, and used by a subject Examples: files, printers, sockets, subjects Actions that subject can perform in a system Examples: shutting down, changing clock
Access Rights Specify the actions that a subject may take on an object Ex: read, write, execute, own Different objects have different possible rights Text File read, write, own Program File execute, own
Safety Is the goal Definition: Ability of the system to allow the user protect their objects from misuse at all times
Access Matrix Conceptually, how AC can be thought of for a system Objects Subjects S 0 S 1 S 2 O 0 O 1 O 2 O n R R,W,O W,E E R R,W,O R R R S n
Capability List i.e. row view with each subject, keep a list of objects they can access Objects Subjects S 0 S 1 S 2 O 0 O 1 O 2 O n R R,W,O W,E E R R,W,O R R R S n
Access List i.e. column view with each object, keep a list of subjects that have access Objects Subjects S 0 S 1 S 2 O 0 O 1 O 2 O n R R,W,O W,E E R R,W,O R R R S n
Mechanisms Subject Request: Read Object Reference Monitor Object Authorization Database
Mechanisms Subject Request: Read Object Reference Monitor Object Check: Does Subject have read rights to Object? Authorization Database
Mechanisms Subject Request: Read Object Reference Monitor Object Check: Does Subject have read rights to Object? Authorization Database Yes, No
Mechanisms Subject Request: Read Object Reference Monitor Yes, Grant: Read Access Object No, Access Denied Check: Does Subject have read rights to Object? Authorization Database Yes, No
Mechanisms Subject Request: Read Object Reference Monitor Yes, Grant: Read Access Object No, Access Denied Check: Does Subject have read rights to Object? Authorization Database Yes, No typically stored with object
Policies Set by object owners and/or administrators used by mechanisms to control access Three types: Discretionary Access Control (DAC) Mandatory Access Control (MAC) Role-Based Access Control (RBAC)
DAC Most Common Access Control Lists (ACLs) each object keeps a list of the subjects who can access it and how Weakness No control over dissemination of information File1 File2 Process1 Deny Alice read, write Allow Everyone read, write Allow Everyone read, write Deny Bob execute Allow Alice execute
MAC System-level policy (DAC is user) Subjects, Objects have security levels that specify the level of trust (subjects) Sensitivity, amount of damage upon release (objects) Can be hierarchical and/or orthogonal Policy specifies the level a subject must have to access an object
MAC Basic access principles READ DOWN: subject level >= object level WRITE UP: subject level <= object level Benefit: Controls the dissemination of information Weakness: Too Rigid
RBAC Subjects are assigned to roles Roles have assigned actions they may take on objects (rights) can be hierarchical and/or orthogonal can aid in applying principle of least privilege
IMPLEMENTATION IN OPERATING SYSTEMS
OSes Covered Basic Unix Unix Variants: POSIX.1e, DTE, SELinux Windows Variants: Windows NT (NT 4.X), XP/2000/Server 2003 (NT 5.X), Vista/Server 2008 (NT 6.X)
Basic Unix owner-group-world DAC permissions for each file object Rights: (r) read (w) write (x) execute rwxrwxrwx owner group world
Issues with Basic Unix Loss of granularity due to only having 3 sets of permissions Consider: system with 5 users owner wants each user to have different rights to a file Not Possible!
Windows DACLs (NT 4.X) objects have a DAC List (DACL) DACLs contain Access Control Entries (ACEs) that specify rights for users allow or deny Access Control Entry (ACE) Type (e.g. Access Denied) Security Identifier (variable length) Access Mask (16 bits) Read, write, execute, etc
Windows Access Checks Checks performed by the Security Reference Monitor (SRM) Denys go first Once denied, always denied created @ logon contains groups & privileges Both threads requesting full access
What about Unix ACLs? POSIX.1e extended basic Unix access rights with ACLs Group Class extended to contain the ACL entries Group triplet -- upper bound on rights that any entry in group class can have
Windows DACLs (NT > 4.X) Access mask extended: 16 bits to 32 bits Allow for creating custom types of files Generic ACEs: built-in Windows objects Object-specific ACEs: custom objects
Common Issues How are access rights inherited to objects? What access rights do processes use on behalf of a user?
Object Access Inheritance Unix has no inheritance for files created in directories Windows NT 4.X used flags in the ACE type field of directories to determine object type: OBJECT_INHERIT and CONTAINER_INHERIT
Problems with NT 4.X Inheritance No accounting for objects of different types Making access changes to tree of objects is ambiguous NT > 4.X modifies inheritance rules and ACEs
NT > 4.X ACEs Generic ACE ACE Size ACE Type Inheritance & Audit Flags Access Mask SID Object-specific ACE ACE Size Inheritance & Audit Flags Object Type Access Mask ACE Type Inherited Object Type Inheritance & Audit Flags Says if the ACE was inherited and whether it should be inherited by containers and/or objects Specifies the type of the object SID Specifies what type of objects will inherit the ACE
NT > 4.X ACE Inheritance Inheritable ACEs From Parent Alice SD CreateFile SD File Inheritable ACEs From Parent Alice CreateFile File
NT > 4.X ACE Inheritance Alice CreateFile Default File Alice CreateFile File
NT > 4.X ACE Propagation When applying changes down a directory tree: Don t want to override locally defined ACEs Ex. ACEs protecting private information Fix: Remove inherited ACEs before propagation Place locally defined ACEs first
Domain &Type Enforcement (DTE) Unix variant Processes grouped into domains Files grouped into types Rules specify which domains can access which types, and how Type inheritance for objects: (1) Previously determined type (2) Rule specifies type for directory (3) Inherited from parent
Security Enhanced Linux (SELinux) Unix Variant Mandatory Access Control system All entities have security labels representing roles and types Access determined by comparing labels according to policy rules held in the security server Process Inheritance based on: role and type of parent process type of program executable File Inheritance based on: type of process (creating it) type of parent directory kind of file
Common Issues How are access rights inherited to objects? What access rights do processes use on behalf of a user?
Typically (Unix & Windows) Uses rights of calling process (unless otherwise specified) Issue: does not distinguish between a user and a process the user started What if process was downloaded from the Internet and cannot be fully trusted?
Windows NT 6.X Added integrity levels Processes and objects have an integrity measure Rights only granted to processes who pass integrity and normal access checks 0 Untrusted Most limited and blocks most write access 1 Low Used by Protected Mode IE and blocks write access to most objects on system 2 Medium 3 High Basic integrity level used by normal applications launched when UAC is enabled Used by admin applications when UAC is enabled or used by normal applications when UAC is disabled and user is administrator 4 System Used by services and other system level applications
Windows NT 6.X Integrity Levels No Write Up Policy for process to objects No Read Up Policy for processes to other processes
Unix Variant Process Rights DTE & SELinux rules specify when process can transition between domains auto(matically) exec choice none not allowed transition by executing a file that is an entry point to the other domain What this means: rules must specify the domains that processes run at and how they transition to that domain
COMMON WEAKNESS ENUMERATION (CWE)
CWE 266 Incorrect Privilege Assignment Vulnerable Program: securityd on Apple MAC OS X 19.3.9 Description: maintains security contexts, performs authorizations Problem: allows users to give themselves rights that should be restricted to Administrators Explanation: On stand-alone machine, probably not an issue On network of machines, administrators might not appreciate it
CWE 271 Execution with Unnecessary Privileges Vulnerable Program: ping (Red Hat Linux 6.2 through 7J) Description: tests a connection to a server Problem: does not drop privileges after receiving a raw socket Explanation: leaves it exposed to bugs that could not occur at lower privileges Developers often don t remember to check these types of issues
CWE 276-279 Improper Settings on Initial Creation of Objects Vulnerable Program: various Description: involves programs that create objects throughout their lifetime Problem/Explanation: define too many (or all) initial access rights developers think they need more rights than they actually do poorly created rights initially are inherited later on developers don t understand inheritance completely set rights in contradiction to user-defined rights developers don t think to check user rights
Avoiding Common Weakness (1) Developers must completely understand their environment (2) Developers must completely understand the requirements of the policy guidelines so they can implement it correctly in the environment (3) Developers should strive to operate at the lowest privilege / access right level as possible