07. Access Control and Policies

Restricting access to the system.

Christchurch hot pools: stored proof of residence (driver’s license, passports) in system; had vulnerable plugin which allowed hacker to access this data. NZ privacy laws: data was not needed after initial verification, so they should have destroyed the data instead of storing it.

Early Memory Access Model

Processes are isolated from each other:

• Supervisor: the sole program allowed to access the registers and load the program from it
• Descriptor register: memory addresses that each program can use
• Memory descriptor: address and size of memory allocations
• If one process is given access to another’s memory (for data sharing), they will have to be next to each other

Relies on a privileged bit to control access to the descriptor register. It must be stored in read-only memory.

Limitations:

• All or nothing: no way of sharing memory between processes
  • Printers etc. require low-level access to I/O
• Sub-routines make the system complex with contiguous memory access
  • Cannot restrict the access to sub-routines in a fine-grained way
• Addresses of processes are linked to the hardware

Multics

• Need for access permissions (e.g. read/write/execute)
• Flexibility between hardware addresses and process memory
• Ability to dynamically link sub-routines

Each process has an array of segment descriptors:

• Pointer to physical start address
• Segment length
• Access control bits
  • R/Read, W/write, X/execute
  • M: supervisor-only flag

This allowed the creation of an access control matrix:

• Subjects: users, groups
• Objects: files, programs, external services etc.
• Row: capability list (C-list): all objects the subject can access
• Column: access control list (ACL): the subjects that can access the given object
• Cells: the permission level (e.g. RWX)
• An instance of the matrix creates the access control policy

Exercise: Assignment 2

• List all subjects in rows:
  • User, superuser, not logged in
    • Project member (i.e. user groups)?
• List all objects in columns:
  • What are objects? Whole pages? Concepts (e.g. user profiles)? Features?
  • Own profile, other public profile info, other private profile info
  • Project
  • Billing

Unix - Discretionary Access Control

Everything is a file.

Is directory
|
v | user | group | other |
d | rwx  |  rwx  |   rwx |
      ^       ^        ^
      |       |        |
setuid (s) setgid (s) t-bit (t)
Special bits replace the execute bit

• A file belongs to an owner, who can define the permissions for all other users
• The group is inherited from a parent directory by default
• Permissions are strictly checked in order: user, group, then other
  • If the owner has no read access (but others do), the owner cannot read

Mandatory Access Control

Security policies are not under the user (or even admin’s) control. In comparison, discretionary access control gives owners (e.g. creator of the file) full control.

This was:

• Created under the multi-level security initiative of the US government
• Defined security clearance levels for subjects/objects
  • Top secret, secret, confidential, controlled unclassified, unclassified

Influenced other access control mechanisms:

• Digital right Management (DRM): prevents sharing of network-accessible resources
• Trusted Platform Module (TPM): monitors and locks the boot process with hashes
  • e.g. Secure Enclave on iOS, Titan-M on Pixel, SELinux on Android
  • Can be used to lock customers to some hardware or from installing different OSes

Rings of protection:

• Ring 0 (inner-most ring) = hardware
  • Backed by hardware
• Access to other rings can only happen when:
  • $P_1$ gives access to $P_2$ process through its $P_1$’s program segment
  • and only in pre-authorized entry points (e.g. phone permissions)

Windows

Access control appeared in Windows NT (NB: UC’s domain is UOCNT):

• Specify groups and users, inspired by UNIX
• New permission attributes:
  • Change ownership
  • Change permissions
  • Delete
• Attributes are not binary (e.g. AccessDenied, AccessAllowed, SystemAudit)
• Containers of objects (since Windows 8) with inheritance of permissions
• Allows more flexibility in installing printer drivers

Can create domains of users:

• Trust between domains can be uni or bidirectional
• Permissions are managed in the registry
• Users are remotely managed by Active Directory
• User profiles and TLS certificates can override permissions

Lots of users, lots of permissions, lots of programs: a nightmare for admins, and incorrect permissions being assigned (and possibly even just giving admin access to everyone).

Take two:

Attack surface hardened with a closed kernel, TPM added, and most drivers were removed from the kernel:

• User account control: all apps run under standard user rights
• Additional permissions explicitly asked (i.e. elevated privilege pop-up at run-time)

Cleaner abstractions with principals and objects:

• Security principals are groups, users, processes etc. with access rights
• Each principal has a security identifier
• Objects can be files, resources (e.g. printers), registry keys -Dynamic access control with contexts added to Active Directory (e.g. work vs. home)

Web Browsers

Reign of cookies:

• Web servers are usually stateless

Security measures:

• Secured transmission (HTTPS/TCP)
• Anti-cross site request forgery: a token generated by the web server, often in a hidden input field
  • Prevents a user accessing attacker-controlled website from making a request to a victim site

Cross-origin:

• Some libraries/style sheets passed at request time
• https://threatpost.com/amazon-alexa-one-click-attack-can-divulge-personal-data/158297/

Hardware-level Protection Mechanisms