BYU logo Computer Science
CS 465 Introduction to Security and Privacy

Access Control

Introductions

  • introductions of two students

Questions on the readings

The readings today are from Operating Systems: Three Easy Pieces, an open source textbook. You shoud have read these sections:

Key concepts

OS Security

  • Everything runs on top of the OS, so if it is insecure … 😱

  • The more complex a prgram, the harder it is to secure. The OS is really complex. So is the browser, which acts almost like a layer above the OS these days.

  • Recall, the OS can:

    • examine or alter any process’s memory
    • read, write, delete or corrupt any file on any writeable persistent
    • storage medium, including hard disks and flash drives
    • change the scheduling or even halt execution of any process
    • send any message to anywhere, including altered versions of those a process wished to send
    • enable or disable any peripheral device
    • give any process access to any other process’s resources
    • arbitrarily take away any resource a process controls
    • respond to any system call with a maximally harmful lie

  • We assume the OS is secure, but a flaw in a program can allow an attacker to hijack the OS

  • Security goals (often abbreviated CIA):

    • confidentiality
    • integrity
    • availability

  • Sometimes we want non-repudiation — an entity that communicates something can’t later deny that it did

  • Important design principles from The Protection of Information in Computer Systems:

    • economy of mechanism: as small and simple as possible
    • fail-safe defaults: default to security
    • complete mediation: any time an action is going to be taken, check security policies
    • open design: assume an attacker knows everything about how the system is built
    • separation of privilege: require separate parties or credentials (e.g. 2FA)
    • least privilege: give a user or process the lowest privileges possible for them to do their job
    • least common mechanism: use separate data structures for separate processes or functionality
    • acceptability: ease of use — users must want to use it

Access control

  • Basic idea

  • Figure out if the request fits within the security policy.

  • If it does, perform the operation. If not, make sure it isn’t done

  • For example

  • If a process wants to open a file for reading and writing, should the OS let it? How does it know?

  • A reference monitor is the part of the OS that enforces policy when a subject requests access to an object

  • Two common methods: access control lists, capabilities

  • Access control list

    • for each object, list which subjects have a type of access
    • e.g. for a file, list which users have read access
    • ror UNIX/Linux, early designers chose to use 9 bits for each file
      • execute (x), write (w), read (r)
      • user/owner (u), group (g), other/world (o)
    • saves lots of space! stored in file metadata in the file system
    • hard to find ALL of the resources a given user has access to

  • Capabilities

    • for each subject, list which objects they have access to
    • e.g. for a user, list which files they have read access to
    • think of a capability as a set of physical keys, giving a process access to certain rooms in a house
    • e.g., a process may be given the capability to read/write files in a given directory
    • capabilities must be controlled by the OS (or else any process could give itself any capability)
    • behind the scenes, an OS like Linux will use capabilities to keep track of access once it is granted

  • Mandatory access control: an organization/government/enterprise controls access for all objects

  • Discretionary access control: the owner of an object controls access

  • Role-based access control: access based on your role (e.g. a customer can order products, an inventory manager can change inventory status, an admin can change roles)

  • Privilege escalation: temporarily gain access beyond normal level, e.g. sudo, setuid bit

Class Exercises

Run a linux-land Docker container:

Terminal window
docker run -d -p 2222:22 --name lotr zappala/linux-land

Login as bilbo. Try:

Terminal window
ls /root

What happens and why?

Login as root. Run this:

Terminal window
# see current permissions on the ls program
ls -al /bin/ls
# set the suid bit on ls
chmod u+s /bin/ls
# see current permissions on the ls program
ls -al /bin/ls
# store a secret in a file
cat > secret.txt
This password will get you into my account: tolkien
# type control-d when done
control-d
# exit
exit

Login as bilbo. Can you see the file? Can you gain access to the secret? If not, how would you do it?