1

UCR

Access Control/Capabilities

Some slides/ideas adapted from Ninghui Li

2

UCR

Why Computers are Vulnerable?

Programs are buggy

Humans make mistakes

Access control is not good enough Discretionary Access Control (DAC) used in Unix and

Windows assume that programs are not buggy

3

UCR

Access Control Check

Given an access request, return an access control decision based on the policy allow / deny

Access Control Check

A Request

Allow / Deny

The Policy

4

UCR

Discretionary Access Control

No precise definition. Basically, DAC allows access rights to be propagated at subject’s discretion often has the notion of owner of an object used in UNIX, Windows, etc.

According to TCSEC (Trusted Computer System Evaluation Criteria) "A means of restricting access to objects based on the

identity and need-to-know of users and/or groups to which they belong. Controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (directly or indirectly) to any other subject."

5

UCR

Analysis why DAC is not Good enough

DAC causes the Confused Deputy problem Solution: use capability-based systems?

DAC does not preserves confidentiality when facing Trojan horses Solution: use Mandatory Access Control?

DAC implementation fails to keep track of for which principals a subject (process) is acting on behalf of Solution: fixing the DAC implementation to better keep track of

principals

Hierarchical authority: OS has access to all Solution: decouple resource management from access control?

6

UCR

The Confused Deputy Problem

SYSX/FORT $OUTPUTCompiler Program

SYSX (Dir)FORTSTATBILL

Write to the bill file

System Admin

$OutputSYSX/BILL

Write output file

User

The Confused Deputy by Norm Hardy: http://www.cap-lore.com/CapTheory/ConfusedDeputy.html

7

UCR

Analysis of The Confused Deputy Problem

The compiler runs with authority from two sources the invoker (i.e., the programmer) the system admin (who installed the compiler and controls

billing and other info)

It is the deputy of two masters There is no way to tell which master the deputy is serving

when performing a write

8

UCR

ACCESS MATRIX MODEL

Ur wown

V

F

Subjects

Objects (and Subjects)

r wown

G

r

rights

9

UCR

Implementation of the Access Matrix

Access Control Lists Encode columns

Capabilities Encode rows

Some other ways (access control triplets, …)

10

UCR

Capability vs. ACL

Consider two security mechanisms for bank accounts.

One is identity-based. Each account has multiple authorized owners. You go into the bank and shows your ID, then you can access all accounts you are authorized. Once you show ID, you can access all accounts. You have to tell the bank which account to take money from.

The other is token-based. When opening an account, you get a passport to that account and a PIN, whoever has the passport and the PIN can access

11

UCR

Capabilities vs. ACL: Ambient Authority

Ambient authority means that a user’s authority is automatically exercised, without the need of being selected. causes the confused deputy problem

No Ambient Authority in capability systems

12

UCR

DAC’s Weaknesses Caused by The Gap

A request: a subject wants to perform an action E.g., processes in OS

The policy: each principal has a set of privileges E.g., user accounts in OS

Challenging to fill the gap between the subjects and the principals relate the subject to the principals

13

UCR

Unix DAC Revisited (1)

Action Process Effective UID

Real Principals

User A Logs In shell User A User A

Load Binary “Goodie” Controlled by user B

Goodie User A ? ?

• When the Goodie process issues a request, what principal(s) is/are responsible for the request?

• Under what assumption, it is correct to say that User A is responsible for the request?

Assumption: Programs are benign, i.e., they only do what they are told to do.

14

UCR

UNIX DAC Revisited (2)

Action Process Effective UID

Real Principals

shell User A User A

Load AcroBat Reader Binary AcroBat User A User A

Read File Downloaded from Network

AcroBat User A ? ?

• When the AcroBat process (after reading the file) issues a request, which principal(s) is/are responsible for the request?

• Under what assumption, it is correct to say that User A is responsible for the request?Assumption: Programs are correct, i.e., they

handle inputs correctly.

15

UCR

Hierarchical Authority – compounding the problem

OS is super-user – has DAC access to all processes

OS Both resource manager and access control manager Can we decouple these roles?

OS exploits are deadly—full authority to access anything is obtained

16

UCR

Hierarchical authority and cross-layer attacks

17

UCR

What should we do instead? Other models of access control

Mandatory access control: remove the discretionary part--you cannot pass on permissions Permissions specified by the system and cannot be changed (e.g., using

labels)

Role based access control: permissions associated with role

Still have to solve the hierarchical authority problem

Security vs. usability

18

UCR

Can we do this in software? Can we, at least, do better?

Are there quick and dirty fixes? Consider, SMEP/SMAP, kGuard, secvisor…

Plan for today: Eric presents CHERI: practical hardware supported capabilities Nael overviews SELinux (software supported access control) and

NIMP (hardware supported access control)

19

UCR

Security Enhanced Linux (SELinux) Developed by National Security Agency (NSA) and

Secure Computing Corporation (SCC) to promote MAC technologies

MAC functionality is provided through the FLASK architecture

Policies based on type-enforcement model

Integrated into 2.6 kernels

Available in most (all?) modern Linux distributions

20

UCR

FLASK

Flux Advanced Security Kernel Developed over the years (since 1992) in several

projects: DTMach, DTOS, Fluke General MAC architecture Supports flexible security policies, “user friendly”

security language (syntax) Separates policies from enforcement Enables using more information when making access

control decisions E.g., User ids, Domains/Types, Roles

21

UCR

Type Enforcement (or Domain Type Enforcement)

Type enforcement first proposed by W. E. Boebert and R. Y. Kain. A Practical Alternative to Hierarchical Integrity Policies. In In

Proceedings of the 8 National Computer Security Conference, 1985.

Aim at ensuring integrity

Key Idea for Type Enforcement: Use the binary being executed to determine access. What do DAC and MAC use?

22

UCR

Rationale of Type Enforcement (1)

Integrity level should be associated with programs (rather than processes) Trust in programs is required for integrity

Examples of assured pipelines: Labeling: All printouts of documents must have security labels

corrected printed by a labeller. Encrypting: Before sending certain data to an output channel, it

must be encrypted by an encryption module Data must pass certain transforming system before

going to certain outputs

23

UCR

Domain-type Enforcement: High-level Idea

Add a new access matrix One row for each subject domain (more or less ) One column for each pair (object type, security class) Each cell contains all operations the subject can perform on

objects of a particular type and security class

24

UCR

Domain-type Enforcement (1)

• Each object is labeled by a type Object semantics Example:

/etc/shadow etc_t /etc/rc.d/init.d/httpd httpd_script_exec_t

• Objects are grouped by object security classes Such as files, sockets, IPC channels, capabilities The security class determines what operations can be performed on

the object• Each subject (process) is associated with a domain

E.g., httpd_t, sshd_t, sendmail_t

25

UCR

Domain-type Enforcement (2)

Access control decision When a process wants to access an object Considers the following: process domain, object type, object

security class, operation

Example: access vector rules allow sshd_t sshd_tmp_t: file { create read write getattr setattr

link unlink rename }

26

UCR

Limitations of the Type Enforcement Model

Result in very large policies Hundreds of thousands of rules for Linux Difficult to understood

Using only programs, but not information flow tracking cannot protect against certain attacks Consider for example: httpd -> shell -> load kernel module

27

UCR

SELinux in Practice

Theoretically, can be configured to provide high security.

In practice, mostly used to confine daemons like web servers They have more clearly defined data access and activity rights. They are often targets of attacks A confined daemon that becomes compromised is thus limited in

the harm it can do. Ordinary user processes often run in the unconfined

domain not restricted by SELinux, but still restricted by the classic Linux

access rights.

28

UCR

Non-inclusive Memory Permissions

Idea: We don’t give full permissions to the OS/hypervisor We also don’t let them manage permissions But we need to let them manage some permissions to do their work

Specify the set of legal permission transitions

29

UCR

NIMP Design