Transcript Slides for lecture 18

CMSC 414
Computer 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
Objects
Subjects
File 1
File 2
User 1
{r,w}
{w}
User 2
{w}
{w}
File 3
…
File n
{r,w}
{r,w}
User 3
{r}
{w}
{r}
{w}
…
User k
{r}
{r}
{r,w}
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
Compare:
Accounting
data
Alice
rw
to:
Accounting
program
Alice
x
Accounting
program
r
Accounting
data
rw
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
reference allow/deny
object
monitor
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
object
subject
request
reference allow/deny
object
monitor
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
I have the
right
to read O1
S1
request
with
capability
reference allow/deny
monitor
O1
Note that request is allowed/denied based on the capability
presented, 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);