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, ACL’s, 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 can’t, 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 stuff…what do we want from sharing?

10. Challenge of Controlled Sharing • All of Saltzer and Schroder’s 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 70’s and 80’s. • 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 talg:friends, system:backup

19. ACL’s • What if I break my matrix down by columns? • Each object has a set of <user, right> tuples • A {<bob, r/w>, <alice,w>} • Properties • Good for many applications (file systems) • Can grow quite large

20. Capabilities • What if I break my matrix down by rows • Alice {<A,r/w>, <B,w>, <C,r>} • Properties • Natural model for delegation (rights coupled to object) • Each tuple can be viewed as a handle to an object

21. Protection Domains • Users don’t 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 ACL’s • Bad News • Very difficult/sometimes impossible to contain damage of malicous root process • Lots of stuff needs root • Users can’t 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 (don’t 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) • {<permissions>, objectid, MAC(msg)} (stateless) • No OS support need, good for distributed systems • Limitations of capabilities • No easy means of revocation • Can’t easily control delegation in a pure model (mostly a red herring) • Doesn’t 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 ISV’s (developers) expect this, very hard to go back! • Wrong granularity • To coarse grain => too much privilege • To fine grain => 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 ACL’s • 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… • ACL’s 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 • Doesn’t 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 => 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 ACL’s, 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 self:unix_dgram_socket create_socket_perms; • allow ftpd_t self:unix_stream_socket create_socket_perms; • allow ftpd_t self:process {getcap setcap}; • allow ftpd_t self:fifo_file rw_file_perms; • allow ftpd_t bin_t:dir search; • can_exec(ftpd_t, bin_t) • allow ftpd_t { sysctl_t sysctl_kernel_t }:dir search; • allow ftpd_t sysctl_kernel_t:file { getattr read }; • allow ftpd_t urandom_device_t:chr_file { getattr read }; • ifdef(`crond.te', ` • system_crond_entry(ftpd_exec_t, ftpd_t) • can_exec(ftpd_t, { sbin_t shell_exec_t }) • ') • allow ftpd_t ftp_data_port_t:tcp_socket name_bind; • 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_t:tcp_socket name_bind; • allow ftpd_t self:unix_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_t:fd use; • allow ftpd_t inetd_t:tcp_socket rw_stream_socket_perms; • # Send SIGCHLD to inetd on death. • allow ftpd_t inetd_t:process sigchld; • ') dnl end inetd.te • ')dnl end (else) ftp_is_daemon • ifdef(`ftp_shm', ` • allow ftpd_t tmpfs_t:file { read write }; • allow ftpd_t { tmpfs_t initrc_t }:shm { read write unix_read unix_write associate }; • ') • # Use capabilities. • allow ftpd_t ftpd_t:capability { net_bind_service setuid setgid fowner fsetid chown sys_resource sys_chroot }; • # Append to /var/log/wtmp. • allow ftpd_t wtmp_t:file { getattr append }; • …

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 < Secret < Top Secret • Horizontal compartments • Nuclear, SIGINT, Biowar, etc. • User has a level, can’t read above that level (violates secrecy), can’t 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 <Top Secret, {Nuclear,Biowar}> <Top Secret, Nuclear> <Top Secret, Biowar> <Top Secret> <Secret, Nuclear> <Secret, biowar> <Secret> <confidential>

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 • Don’t 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.