CMSC 414 Computer and Network Security Lecture 18

CMSC 414Computer and Network Security

Lecture 18

Jonathan Katz

Access control matrix

Matrix indexed by all subjects and objects– Characterizes rights of each subject with respect to

each object

Formally: set of objects O and subjects S, set of possible rights

Matrix with subjects labeling the rows and objects labeling the columns– The entry (s, o) contains the rights for s on o

– Examples: read/write/execute/etc.

Example

File 1 File 2 File 3 … File n

User 1 {r,w} {w} {r,w}

User 2 {w} {w} {r,w}

User 3 {r} {w}

…

User k {r} {r} {r,w} {r} {w}

Subjects

Objects

Granularity/complexity

In theory, arbitrary level of granularity, e.g.,– Subjects: functions within processes

– Objects: characters within files

– Rights: write, append, increment-only, delegation, …

In practice, a decision must be made as to the level of granularity that will be supported

Granularity/complexity

Trade-off is obvious:– Fine-grained access control gives “better security”

• Least privilege

– Coarse-grained access control more efficient

Example: Unix granularity

Subjects: users– Users can be in groups

– Users can change their current group (to any group of which they are a member)

Objects: files– Specify access rights for the owner, the group to which

the owner belongs, and other

Rights: read, write, execute

Mediation

More fine-grained control can sometimes be achieved via mediation/indirection

Mediation

Accounting data

Alice rw

Accounting program

Accounting data

Alice x

Accounting program

r rw

Compare:

to:

Mediation/indirection

Alice can read and write the accounting data– But she shouldn’t be allowed to arbitrarily modify the

accounting data!

Solution: mediate access via the accounting program– Note that now the accounting program may potentially

have to implement access control for different users

– Vulnerabilities in the accounting program can potentially be exploited…

Example: Unix mediation By default, programs run with the rights of the

user calling the program– What if users need to be able to access a restricted file

(e.g., /etc/passwd)?

Executables have a ‘setuid flag’ that can be set by the owner of the executable– If set, the program runs with the rights of the file owner

Running programs have a uid and an effective uid– If setuid off, uid=euid=caller– If setuid on, uid=caller, euid=owner

Access control matrix

The access control matrix provides a conceptual way to think about the rights in the system

It can also be a way to implement access control

subject request referencemonitor

allow/deny object

Drawbacks of access control matrix

An access control matrix is useful conceptually, but would be inefficient if used to actually implement access control– Number of subjects/objects is very large (|S|x|O|x|R|)

– Most entries blank/default

– One central matrix modified every time subjects/objects are created/deleted or rights are modified

• Central point of failure in the system, heavy load

– “Small’ change can result in “many” changes to the access control matrix

• E.g., making a file publicly readable

Solutions

Compress the access control matrix– E.g., use groups/roles (will discuss later with regard to

role-based access control)

– Coarse-grained access rights to get better efficiency

Store the matrix by its columns or rows– Access control lists (ACLs) and capabilities

– This also ends up reducing the storage

Access control lists (ACLs)

Can be viewed as storing the columns of the access control matrix with the appropriate object

Ideally, one list per object showing all subjects with access and their rights– Missing subjects given “default” access

OS will have to check ACL (using the subject associated with the program) each time a program tries to access an object

Used in, e.g., Unix

Access control lists, pictorially

subjectrequest reference

monitorallow/deny

object

object

object

S1: {r, w}

S2: {w}

S3: {r, w}

S4: {}

Advantages and disadvantages

Advantages– Well suited for users managing rights on their own files

– Fits well with how OS’s manage files

Disadvantages– Not well suited when subjects constantly being

added/deleted, or where delegation of rights is desired

– Can be difficult to revoke all access of a subject, or to find all files that a subject is able to access

– Difficult to manage in distributed systems (e.g., multiple copies of a file that should always have the same access rights)

Capabilities

Can be viewed as storing the rows of the access control matrix with the appropriate subject

View subject as having a “ticket” which grants access to an object– A capability is an unforgeable token giving user access

to an object and describing the allowed access

– In principle, can be very expressive (capability could represent a predicate that is evaluated)

Capabilities: two approaches

Ticket is held by the OS, which returns to the subject a pointer to the ticket

Ticket is held by the user, but protected from forgery by cryptographic mechanisms– How…?

– Ticket can then be verified by the OS, or by the object itself (e.g., if the object is a server)

• Well suited for distributed systems

Capabilities, pictorially

S1 requestwith

capability

referencemonitor

allow/deny O1

I have the right

to read O1

Note that request is allowed/denied based on the capabilitypresented, not based on capabilities held

Advantages of capabilities

Better at enforcing “principle of least privilege” – Provide access to minimal resources, to the minimal set

of subjects

See next example

Example use of capabilities

From “The Confused Deputy,” by Hardy

Compiler in directory SYS– User can provide file for debugging output

– Compiler writes statistics to SYS/stat• Compiler allowed to write to SYS

User set debugging file to SYS/billing– Allowed…

– The effect was to overwrite the billing file!

Pseudocode

// Say argv[1] = “SYS/billing”

stat = fopen(“SYS/stat”, “rw”); // allowed!debug = fopen(argv[1], “rw”); // allowed!

write(statistics, stat);write(debugging_info, debug);

Example continued… Underlying problem: authority from two sources:

static + authority of caller– The problem was not the compiler having the wrong

authority, but exercising its authority for the wrong purpose

How to solve this problem?– Check filenames explicitly?

• They can change…• Legitimate access to SYS files…

– Add specific list of conditions?• Complexity grows

– Straightforward use of ACLs does not work… (why?)

Suggested solution

Use capabilities:– Give compiler capability to write to SYS/stat

• Compiler does not even need to be aware of the filename it is writing to; the capability takes care of this

– Caller can provide additional capabilities, as needed

– Compiler must explicitly designate capabilities to use in a particular situation

• In this case, will designate the capabilities presented by the caller!

Pseudocode

// Say argv[1] = “SYS/billing”

stat=fopen(“SYS/stat”, “rw”, compiler_cap); // allowed!debug = fopen(argv[1], “rw”, user_capability); // not allowed! Compiler has access, // but not using that capability

write(statistics, stat, compiler_capability);write(debugging_info, debug, user_capability);