CMSC%20414%20Computer%20and%20Network%20Security%20Lecture%2013 - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

CMSC%20414%20Computer%20and%20Network%20Security%20Lecture%2013

Description:

CMSC 414 Computer and Network Security ... run process using the name of the caller, ... invalidate the entry in the table Difficult to revoke access of a single ... – PowerPoint PPT presentation

Number of Views:13
Avg rating:3.0/5.0
Slides: 43
Provided by: jka55
Learn more at: http://www.cs.umd.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: CMSC%20414%20Computer%20and%20Network%20Security%20Lecture%2013


1
CMSC 414Computer and Network SecurityLecture 13
  • Jonathan Katz

2
Announcement
  • Midterm exam Oct. 28, covering material through
    Oct. 21

3
Access control
4
Some terminology
  • Protected entities objects O
  • Active objects subjects S (i.e.,
    users/processes)
  • Note that subjects can also be objects
  • Typically, each subject associated with some
    principal/owner
  • In identity-based access control, security
    policies ultimately refer to the human users who
    are the principals
  • Subjects/objects can be
  • Files
  • Processes
  • Functions/variables (within a program)
  • System resources (servers, printers, etc.)

5
Access control
  • Determining who has access to specific files, or
    other system resources

referencemonitor
subject
object
request
allow/deny
6
Secure mediation
  • Security kernel, Trusted Computing Base (TCB)
  • Responsible for implementing the reference
    monitor
  • Must be tamper-resistant
  • Must be impossible to circumvent
  • I.e., all access to objects must be mediated by
    the TCB
  • Ideally, small and simple enough that it can be
    tested and analyzed so as to ensure correctness

7
Authentication vs. authorization
  • Authentication
  • Determining the identity of a user
  • May also involve verification of IP address,
    machine, time, etc
  • Determine whether a user is allowed to access the
    system at all
  • Used for audit, not just authorization
  • We will return to this later for now we assume
    it
  • Authorization
  • Assuming identity of user is known, determine
    whether some specific action is allowed

8
General principles
  • Fine-grained access control is better
  • E.g., control access to files not just
    directories
  • Least privilege
  • Grant minimum abilities necessary to complete
    task
  • Closed vs. open policies
  • Closed disallowed unless explicitly allowed
  • Open allowed unless explicitly disallowed

9
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 A 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.

10
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
11
Access control matrix
  • The access control matrix provides a useful way
    to think about the rights in the system
  • It can also be a way to implement access control

referencemonitor
subject
object
request
allow/deny



12
More complex access control
  • In general, rights may be functions
  • Actual rights depend on the system state
  • Equivalently, may depend on system history
  • Rights can form hierarchies
  • E.g., right X implies right Y
  • How fine-grained the access control is depends on
    how fine-grained the rights are
  • E.g., write vs. append-only

13
Coarse-grained access control
  • Access control can also be more coarse-grained
    than a full-blown access matrix would imply
  • E.g., in unix
  • For a file, specify access rights for the owner,
    the group to which the owner belongs, and
    everyone else
  • Possible rights are read, write, execute

14
Drawbacks of access control matrix
  • Number of subjects/objects is very large
  • Most entries blank/default
  • One central matrix modified every time
    subjects/objects are created/deleted or rights
    are modified
  • Small change can result in many changes to
    the access control matrix
  • E.g., making a file publicly readable

15
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
  • Easy to make an object public

16
Access control lists, pictorially
object
S1 r, w
S2 w
S3 r, w
S4
referencemonitor
request
allow/deny
subject
object
object
17
ACLs in practice
  • Again, full granularity may not be supported
  • E.g., unix allows permissions set for the owner
    of the file, the group to which the owner
    belongs, and everyone else (all)

18
Conflicts?
  • Need a mechanism for handling conflicts
  • E.g., what if group has fewer rights than all?
  • Resolution (in unix)
  • if user owner then owner permission
  • else if user in group then group
    permission
  • else all permission
  • In general, could have been done differently

19
Capabilities
  • Can be viewed as storing the rows of the access
    control matrix with the appropriate subject
  • Analogy user has a ticket which grants access
    to an object
  • A capability is an unforgeable token giving user
    access to an object and describing the level of
    allowable access
  • Capabilities can specify new types of rights

20
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

21
Capabilities, pictorially
I have the rightto read O1

referencemonitor
S1
O1
request
allow/deny
22
ACLs vs. capabilities
  • Access control list
  • ACL associated with each object
  • Upon request, check user/group against the ACL
  • Relies on authentication of the user
  • Capabilities
  • Can be passed from one user/process to another
  • Upon request, check validity of capability
  • No need to know the identity of the user/process
    making the request

23
ACLs vs. capabilities
  • How would delegation be handled using ACLs vs.
    using capabilities?
  • ACL run process using the name of the caller, or
    OS can explicitly support delegation
  • Capabilities allow delegation for free
  • How can a user make a file public when
    capabilities are used?
  • Maybe its a good thing that this is hard to do!

24
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!

25
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?)

26
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!

27
More advantages of capabilities
  • When a subject holds a capability for an object,
    it knows it has access to that object
  • In contrast, with ACLs it is impossible for a
    subject to obtain a list of all files it is
    allowed to read
  • Capabilities allow finer-grained treatment of
    subjects
  • E.g., at the process level rather than the user
    level
  • Why cant this be done with ACLs?
  • Capabilities allow easier delegation
  • In ACLs, usually all-or-nothing (if allowed at
    all)
  • With capabilities, can delegate a subset of the
    rights you have

28
Advantages of capabilities
  • Better at enforcing principle of least
    privilege
  • Provide access to minimal resources, to the
    minimal set of subjects

29
Confinement myth
  • Myth Capabilities can be delegated at will and
    therefore cannot be confined
  • Mistaken assumption that the ability to
    write/read files translates into the ability to
    read/write capabilities
  • Capabilities are not just files they can be
    typed by the OS
  • Can be set up so that A can delegate a capability
    to B only if A is authorized to pass capabilities
    to B

30
Revoking capabilities
  • Revocation is more difficult with capabilities
    than with ACLs
  • One solution indirection
  • Capabilities name an entry in a table, rather
    than the object itself
  • To revoke access to object, invalidate the entry
    in the table
  • Difficult to revoke access of a single user
  • Capabilities can also expire with time
  • If OS stores capabilities, can delete upon
    request
  • Requires object to recall to whom capabilities
    given

31
Disadvantages of capabilities
  • Overhead
  • Revocation more difficult
  • Controlling delegation more difficult
  • Making files world-readable more difficult
    (impossible?)

32
Access control policies
33
Access control policies
  • Discretionary access control (DAC)
  • Mandatory access control (MAC)
  • Role-based access control (RBAC)
  • Not necessarily mutually exclusive
  • A system may use different mechanisms for
    different resources
  • Or, apply two policies allow access only if both
    allow

34
DAC
  • Controls based on the identity of the user and
    access rules
  • Rights can be delegated at users discretion
  • Most common

35
MAC
  • Controls based on comparing security labels with
    security clearances
  • Delegation not allowed
  • Primarily used in military environments

36
RBAC
  • Controls based on a users (or programs) role,
    not their identity
  • Users rights can change depending on their
    current role
  • More recent proposal

37
Discretionary access control
38
Discretionary access control
  • Access control rights determined (to some extent)
    by users themselves, not by the system
  • I.e., users own certain resources, and can
    decide who has access to them and not
  • E.g., chmod in unix

39
Delegation (one approach)
  • We augment the access control matrix to include
    subjects as objects
  • AS,S control always
  • When S creates S, a new column and row is
    created AS,S is set to control
  • Rights on other objects can also come with or
    without a copy flag set
  • Allows delegation, either with or without
    delegation of copy flag
  • Denote by adding to the right

40
Delegation (by S)
  • Delegate r, r on X to S by S allowed if any
    of the following hold
  • AS,X r (i.e., S has right r on X, and copy
    flag set)
  • AS,X owner (i.e., S owns X)
  • AS,X r and AS,S control (i.e., S has
    right r on X, and S created S)
  • Delete r on X from S by S allowed if any of
    the following hold
  • AS,X owner
  • SS,S control

41
Creating a new subject
  • When S creates S, why not populate row S with
    the same access rights that are in row S?
  • Least privilege

42
Note
  • The OS can be treated as a subject with all
    rights
  • Examples
  • When Alice logs in do
  • Create shell process p with rights appropriate
    for Alice
  • Delegate ownership of p to Alice
  • When Alice creates a file
  • OS creates file f
  • OS delegates own, read, write to Alice on file f
About PowerShow.com