Access Control and Protection

1
Access Control and Protection

• CS155 Lecture 2
• Tal Garfinkel

2
Todays Agenda

• Lots of new language/models for talking about
  security systems
• Capabilities, ACLs, DTE
• How do we talk about existing systems
• What to consider in a new design?
• Discussion of how some existing systems work e.g.
  unix access controls

3
Overview

• Access control What and Why
• Abstract Models of Access Control
• The Unix Access Control Model
• Capabilities
• Beyond the Unix Model
• Multilevel Security

4
What goes into system security?

• Authentication (password/crypto/etc.)
• Who are you?
• this is a big part of CS255
• Authorization (Acess control)
• What are you allowed to do.
• Focus is policy
• Enforcement Mechanism
• - How its policy implemented/enforced
• Today we are mostly interested in 2, will touch
  on 3
• Note split between policy and mechanism
  sometimes a false dichotomy.

5
Night Club Example

• Authentication
• ID Check
• Access Control
• Over 18 - allowed in
• Over 21 - allowed to drink
• On VIP List - allowed to access VIP area
• Enforcement Mechanism
• Walls, Doors, Locks, Bouncers

6
Night Club Example More Interesting Phenomena

• Tickets
• Name or anonymous?
• Date
• What if you want to leave and come back
• Hand stamp or bracelet

7
Why this Tangent?

• We can find logical models to study these
  systems?
• We can use these models to design new systems?
• Security systems are everywhere, looking at the
  real world key to building your intuition.

8
What do we use this for?

• Express information access policies.
• Who can access my files, who cant, how.
• Sandboxing Minimize damage inflicted by malicous
  program.
• Privilege Seperation Allow programs to be
  written to minimize damage in case of failure.
• Think about compartments in a ship
• Defense-in-Depth
• - programmers make mistakes,protection systems
  fail, redundancy always a good thing!!

9
Basic Design Space

• All security architectures are Isolation
  Controlled Sharing
• Just Isolation
• Unplug the network cable! (airgap provides almost
  perfect isolation).
• Segment your network physically
• Put red tape on one set of wires and machines,
  black tape on another, blue on another.
• Make sure colors always match!
• Military exploits this approach to separate
  classified, secret, topsecret networks.
• Most of us need to share stuffwhat do we want
  from sharing?

10
Challenge of Controlled Sharing

• All of Saltzer and Schroders principles are
  vital,these two are hard.
• Principle of Least privilege
• Make controls granular enough and apply them to
  enforce them to minimize harm.
• Psychological acceptability
• Get as close to the users mental model (be it the
  programmer, user or admin) as possible.
• Reconciling these two is a fundamental challenge.

11
Operating Systems Our focus today

• Most heavily studied area for access control
• First computers where single user/no network
• Timesharing systems introduced need for access
  control
• studied heavily in the 70s and 80s.
• Still an open research area, why?
• First 20 years restrict what a user can do with
  data, focus on military problems, thought problem
  was malicous users
• Last 10 Malicous applications the primary
  problem.
• Another answer Right Access control policy
  dictated by Usage models, Threat Model,
  Applications -- we still have lots to learn about
  how programs are built, how people use them.

12
Access Control vs. IDS and AV

• Soundness (can I make a definite allow/deny
  decision)
• Difference between access control and intrusion
  detection
• An IDS makes a probablistic statement i.e. this
  action is probably bad - allows catching a
  broader range of behaviors, at the cost of
  enforcement.
• An IDS that is 100 accurate should be doing
  enforcement, it is then an IPS (access control
  system)
• Completeness (do I catch every bad action)
• Access control vs. AV
• Access control systems should (in theory enforce
  some property) -- e.g enforce these rules on
  information flow.
• AV systems often rely more on un-sound blacklist
  approach, hard to make strict statements about
  what your getting
• In the real world, distinctions often unclear
• Your AV product may do some access control

13
Abstract Models of Access Control
14
Subjects and Objects

• Subjects
• can be processes, modules, roles
• Objects
• can be files, processes, etc.
• Authentication often used to bootstrap subjects,
  but not necessary.
• e.g. process assumes identity of one subject,
  then another.

15
Elementary Forms

• Authentication Authorization
• e.g. safes
• Whitelists/Blacklists (Single object, multiple
  Subjects)
• Examples Spam prevention
• Blacklists
• Default on (fail open)
• Hard to reason about who can access system
• Whitelists
• Default off (fail closed)
• Have to deal with adding whitelist entries
• Challenges
• Hard to manage if rapidly changing set of
  principles
• Both can grow quite large

16
Access Control Matrix

• Instantaneous protection state of a system
• Dynamically Changing!
• How can we extend this model?

Objects
A
B
C
D
alice
bob
subjects
charlie
dave
17
Adding Access Rights

• Access Rights
• e.g. Simple Read, Write
• e.g. Complex execute, change ownership

Objects
A
B
C
D
alice
bob
subjects
charlie
dave
18
Grouping

• Subjects
• Groups e.g. staff alice,dave, students
  bob, charlie
• Objects
• Types e.g. system_file A,B, user_file C,D
• Can have compound names
• e.g. in AFS talgfriends, systembackup

19
ACLs

• What if I break my matrix down by columns?
• Each object has a set of ltuser, rightgt tuples
• A ltbob, r/wgt, ltalice,wgt
• Properties
• Good for many applications (file systems)
• Can grow quite large

20
Capabilities

• What if I break my matrix down by rows
• Alice ltA,r/wgt, ltB,wgt, ltC,rgt
• Properties
• Natural model for delegation (rights coupled to
  object)
• Each tuple can be viewed as a handle to an object

21
Protection Domains

• Users dont exist
• Machines, processes, modules,do
• Protection domain is an abstract object that can
  have
• A namespace (e.g. view of the file system)
• A userid or group ID
• A set of objects it holds (capability list)
• A set of rights it holds (permissions)
• How does protection get enforced?
• Language type systems, hardware MMU (Processes,
  virtual machines), compilers (SFI)
• Not our primary interest today

22
The Reference Monitor

• An abstract model of protection
• Sometimes quite close to implementation
• e.g. SELinux (Flask Architecture)
• In practice should offer
• Complete mediation
• Be Tamper proof
• Be small enough to understand (verify)
• Important Idea Computer systems are BIG and
  Complex, Security relavent part often SMALL,
  extract that part out that deals with security so
  that we can understand/verify it.

23
Unix Access Control

• Basics, limitations, extensions

24
Unix Resource

• Files
• Includes devices, IPC (domain sockets, named
  pipes, mmap shared memory)
• Network
• TCP/UDP port address space
• Other
• Sys V IPC has its own name space
• ability to load kernel modules

25
Unix Identities

• Each process has set of identities used to make
  access control decisions.
• Conceptually uid/euid, gid/egid most important
• In practice, a bunch of other details, see
  reading.
• euid used for access control decisions
• Allows process to drop and resume privilege
  temporarily
• Changing uid/euid allows dropping privilege
  permanently.

26
File system access control
user group other

• -rwxrwxrwx
• -rw------- talg talg vimrc
• -r-sr-xr-x root wheel chpass
• New files created according to umask
• setuid bit for executables - changes uid to uid
  of file owner on exec() of file.
• Execute on directory implies access to directory.

27
What can you do with identities

• Lots of hard coded rules
• Highest privilege uid is root (uid 0), has most
  privilege,
• Access privileged ports, override file
  permissions, load kernel modules, etc.
• Once you have root, you own the system
• this is a source of many problems.
• Process with a given euid can send signals to
  other processes with that uid, ptrace() those
  processes, etc.
• Basically no protection between processes with
  same uid.
• Good news
• Works decently well on multi-user system where
  programs are not malicous -- shortcomings can be
  fixed with file system ACLs
• Bad News
• Very difficult/sometimes impossible to contain
  damage of malicous root process
• Lots of stuff needs root
• Users cant protect themselves from bad apps,
  i.e. apps totally trusted!!

28
Dropping privilege

• Only available to root
• To prevent programmer errors
• Assume role of less privileged user for most
  operations (seteuid)
• Let OS do its job
• Only keep privilege long enough to do what you
  need.
• Temporary, program can resume root privilege at
  will
• Essential for some things in unix (e.g. race free
  file open)
• NEVER try to impersonate another user as root!
• You will fail
• To prevent malicous code from inflicting damage
• Drop privilege permanantly (often accompanied by
  fork()).
• Works well if there is a before-time (with
  privilege)/after-time(without privilege) model.
  e.g. daemons that need root to listen to
  privileged port.

29
Seperating Time of Check and Time of Use - A
Really Bad Thing

• Example access() system call.
• int access(const char path, int mode)
• From the man page
• Access() is a potential security hole and should
  never be used.
• Problem as soon as you get a result from
  access(), its invalid. Permissions could have
  changed.
• Checking Permission/obtaining resource must be
  atomic!
• Solution Never use access(), instead look up
  programming guidelines for your OS.
• Hint Never make up your own solution!

30
Capabilities

• They are cool

31
Confused Deputy Problem

• Pay-to-play compiler service (its an old problem)
• Compiler service takes file and compiles it for
  user
• User hands compiler path for compilers own
  billing file
• Compiler overwrites billing file
• Compiler was a confused deputy - acting on behalf
  of user.
• Solutions
• Drop privilege to that of user to open file (more
  error prone, common source of bugs)
• Have user pass capability to compiler (less error
  prone).
• Capability advocates love to point this out as
  reason to use capabilities.

32
File descriptor passing the poor mans capability
system

• File descriptors are capabilities
• Ability to delegate files by passing descriptors
  over a unix domain socket (sendmsg(), recvmsg())
• Supports privilege seperation
• One process runs as root, opens a unix domain
  socketpair.
• Forks() another process, drops privilege
• More privilege process can pass descriptors to
  less privilege process, also do other stuff e.g.
  manage crypto keys.
• Can apply this paradigm ad naseum i.e. multiple
  unprivileged processes.
• Trade-offs
• Positive Great way to make more robust software
• Negative sometimes very hard to do after the
  fact (dont believe the hype), requires pretty
  clueful programmers up front.

33
Capabilities have lots of nice properties

• Natural model for delegation
• Just pass handle to object
• No ambient privilege
• Access control explicit not implicit
• Separate access checking from use
• E.g. fd open() vs. read(fd), write(fd)
• Useful design pattern for ammoritizing the cost
  of permission checks
• Powerful extensibility in languages that support
  capabilities natively
• Wrap one object in another object.

34
Still More

• Cryptographic Capabilities
• Nonce as index into table (stateful)
• ltpermissionsgt, objectid, MAC(msg) (stateless)
• No OS support need, good for distributed systems
• Limitations of capabilities
• No easy means of revocation
• Cant easily control delegation in a pure model
  (mostly a red herring)
• Doesnt always suit your problem

35
Some Real World Access Control Mechanisms

• Or, overcoming the shortcomings of the original
  Unix model.

36
Dangers of bad access control model

• Too much privilege!
• Original Unix architecture suffers severly
• Windows world even worse
• Once ISVs (developers) expect this, very hard to
  go back!
• Wrong granularity
• To coarse grain gt too much privilege
• To fine grain gt too many knobs, no one knows how
  to use it
• (SELinux struggles with this, its gotten better,
  but still not for the faint of heart)
• Compromise
• Protection Profiles, Roles, etc. - use fine grain
  permissions to build up common case profiles.

37
File system ACLs

• Basic Problem
• I want to do a project with a new group, how do I
  share files with only them without involving my
  sysadmin?
• Ghetto style
• Create a directory accessible but not readable by
  everyone
• Make directory (or files) in that directory with
  secret name
• Hand out name as a capability
• Gross and many limitations
• ACLs a better soluation
• User created groups, user setable list of
  groups/users on files/directories
• Almost everywhere now
• AFS, NTFS, NFSv4, FreeBSD, Solaris, ZFS, etc.

38
Chroot()

• Basic idea Allow process to change file system
  root e.g. chroot(/home/apache/base)
• Variety of sharp edges due to power of root
  user, ptrace(), etc.
• BSD Jail tries to fix this.
• Fundamental problem, limited controlled sharing.
• Still, a useful primitive
• Richer primitive in plan9, a research OS.

/
home
etc
bin
apache
base
etc
bin
39
Posix Capabilities

• Paritioning power of root
• CAP_DAC_OVERRIDE ignore normal file permissions
• CAP_CHOWN allow arbitrary chown
• CAP_SYS_NET_BIND_SERVICE allow bind of TCP/UPD
  sockets below port 1024
• CAP_NET_RAW allow raw socket access (can create
  arbitrary ethernet frames)
• Improvement on setuid
• Doesnt help with files
• Fixed granularity

40
Sandboxing Systems

• Examples AppArmor (SuSe), Systrace, Janus

41
SELinux

• Adding MAC to Linux
• Flexible policy architecture
• DTE, RBAC, MLS
• Default uses combination of RBAC and DTE
• Checks applied if existing unix model succeeds
  e.g. if access fails, additional checks not
  invoked
• Most folks never use MLS

42
Domain and Type Enforcement

• Generalization of Access Control Matrix
• Processes have a domain
• Objects (generally files) have a type.
• Stored in extended file attribute
• Type set at system configuration time.
• Example
• assign -u /home user_t
• assign -u /var spool_t
• Entry point to domain is generally a binary e.g.
  (exec /usr/bin/lpd gt domain lpd_t)
• App can request a domain transition to drop
  privilege
• Nice compared to path base model in that more
  robust to file rename(), can be less prone to
  problems due to symlinks, etc.

43
RBAC

• Yet another generalization of our access control
  matrix
• Add yet another label to processes
• Instead of uid, access control decisions based on
  role
• e.g. Bob acting as backup manager vs. bob acting
  as printing manager.

44
A few words on Policy Languages

• Policy language at heart of rationale for access
  control
• Look at policy spec instead of entire
  program/system
• Clarity/simplicity key
• Even ACLs have a policy language
• Different requirements than programming language
• Often non-expert users
• Must be right the first time!
• Tension between flexibility/expressiveness and
  simplicity
• Compare ACLs, to AppArmor to SELinux

45
Sample SELinux TE Policy for FTPD

• Rules for the ftpd_t domain
• type ftp_port_t, port_type
• type ftp_data_port_t, port_type
• daemon_domain(ftpd, , auth_chkpwd')
• type etc_ftpd_t, file_type, sysadmfile
• can_network(ftpd_t)
• can_ypbind(ftpd_t)
• allow ftpd_t selfunix_dgram_socket
  create_socket_perms
• allow ftpd_t selfunix_stream_socket
  create_socket_perms
• allow ftpd_t selfprocess getcap setcap
• allow ftpd_t selffifo_file rw_file_perms
• allow ftpd_t bin_tdir search
• can_exec(ftpd_t, bin_t)
• allow ftpd_t sysctl_t sysctl_kernel_t dir
  search

• ifdef(ftpd_daemon',
• define(ftpd_is_daemon', ')
• ') dnl end ftpd_daemon
• ifdef(ftpd_is_daemon',
• rw_dir_create_file(ftpd_t, var_lock_t)
• allow ftpd_t ftp_port_ttcp_socket name_bind
• allow ftpd_t selfunix_dgram_socket sendto
• can_tcp_connect(userdomain, ftpd_t)
• ',
• ifdef(inetd.te',
• domain_auto_trans(inetd_t, ftpd_exec_t, ftpd_t)
• ifdef(tcpd.te', domain_auto_trans(tcpd_t,
  ftpd_exec_t, ftpd_t)')
• Use sockets inherited from inetd.
• allow ftpd_t inetd_tfd use
• allow ftpd_t inetd_ttcp_socket
  rw_stream_socket_perms
• Send SIGCHLD to inetd on death.
• allow ftpd_t inetd_tprocess sigchld

46
Whole System Containers

• Solaris Zones, OS Level Virtual Machines
• Given application completely private view of OS
• Great for isolation, no sharing model.
• Same camp as virtual machines
• the right tool for some jobs
• large topic in its own right

47
Multilevel Security
48
Classical military model

• Vertical classification levels
• Confidential lt Secret lt Top Secret
• Horizontal compartments
• Nuclear, SIGINT, Biowar, etc.
• User has a level, cant read above that level
  (violates secrecy), cant write below that level
  (leaks data).
• Process can begin with
• Upperbound (read),lowerbound (write)
• Lower bound raised every time information read
  from above.

49
Bell-Lapadula

• No read up, no write down

ltTop Secret, Nuclear,Biowargt
ltTop Secret, Nucleargt
ltTop Secret, Biowargt
ltTop Secretgt
ltSecret, biowargt
ltSecret, Nucleargt
ltSecretgt
ltconfidentialgt
50
MLS in the world

• Classification level added by tagging files
• Just like DTE
• Everything tends to flow up
• Ends up being very cumbersome in practice
• Declassification
• Dont know how to automate this, human in the
  loop
• Becomes a bottle neck in critical situations
  (e.g.9/11)
• Almost no one uses this in practice
• Tagging data with sensitive labels a cool idea,
  maybe could be used to help protect your personal
  data from malware
• Ongoing research area.

51
Biba-Integrity Model

• Cool Observation Integrity the opposite of
  secrecy -- low integrity data flowing upwards
  leads to system compromise.
• Biba Rules
• No read down
• No write up
• Again, tends to be kind of unwieldly, can make
  sense for some systems.

52
The Confinement Problem

• In real life, really really hard to prevent to
  colaborating processes from communicating (say in
  order to write down).
• Often due to timing channels
• Communication path called a covert channel
• Real world systems that care (very very few) try
  to limit bandwidth.
• Lampsons Notes on the confinement Problem a
  must read.

53
Closing thoughts
54
Most of you will go off to companies to write code

• Many attacks seen in the wild could have been
  rendered moot if software used access controls
  properly.
• Learn the access control system of your language
  runtime and OS
• Learn their strengths and pitfalls.
• Build systems according to saltzer and schroders
  principles.
• Be conservative in your design, assume things
  will fail, attempt to minize harm
• .
• Building things right requires a bit more effort.
• Fixing things later requires far more
• sometimes impossible or impractical.