1 UCR Access Control/Capabilities Some slides/ideas adapted from Ninghui Li

2 UCR Why Computers are Vulnerable? Programs are buggy Humans make mistakes Access control is not good enough  Discretionary Access Control (DAC) used in Unix and Windows assume that programs are not buggy

3 UCR Access Control Check Given an access request, return an access control decision based on the policy  allow / deny Access Control Check A Request Allow / Deny The Policy

4 UCR Discretionary Access Control No precise definition. Basically, DAC allows access rights to be propagated at subject’s discretion  often has the notion of owner of an object  used in UNIX, Windows, etc. According to TCSEC (Trusted Computer System Evaluation Criteria)  "A means of restricting access to objects based on the identity and need-to-know of users and/or groups to which they belong. Controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (directly or indirectly) to any other subject."

5 UCR Analysis why DAC is not Good enough DAC causes the Confused Deputy problem  Solution: use capability-based systems? DAC does not preserves confidentiality when facing Trojan horses  Solution: use Mandatory Access Control? DAC implementation fails to keep track of for which principals a subject (process) is acting on behalf of  Solution: fixing the DAC implementation to better keep track of principals Hierarchical authority: OS has access to all  Solution: decouple resource management from access control?

6 UCR The Confused Deputy Problem SYSX/FORT $OUTPUT Compiler Program SYSX (Dir) FORT STAT BILL Write to the bill file System Admin $Output SYSX/BILL Write output file User The Confused Deputy by Norm Hardy:

7 UCR Analysis of The Confused Deputy Problem The compiler runs with authority from two sources  the invoker (i.e., the programmer)  the system admin (who installed the compiler and controls billing and other info) It is the deputy of two masters  There is no way to tell which master the deputy is serving when performing a write

8 UCR ACCESS MATRIX MODEL U r w own V F SubjectsSubjects Objects (and Subjects) r w own G r rights

9 UCR Implementation of the Access Matrix Access Control Lists  Encode columns Capabilities  Encode rows Some other ways (access control triplets, …)

10 UCR Capability vs. ACL Consider two security mechanisms for bank accounts. One is identity-based. Each account has multiple authorized owners. You go into the bank and shows your ID, then you can access all accounts you are authorized.  Once you show ID, you can access all accounts.  You have to tell the bank which account to take money from. The other is token-based. When opening an account, you get a passport to that account and a PIN, whoever has the passport and the PIN can access

11 UCR Capabilities vs. ACL: Ambient Authority Ambient authority means that a user’s authority is automatically exercised, without the need of being selected.  causes the confused deputy problem No Ambient Authority in capability systems

12 UCR DAC’s Weaknesses Caused by The Gap A request: a subject wants to perform an action  E.g., processes in OS The policy: each principal has a set of privileges  E.g., user accounts in OS Challenging to fill the gap between the subjects and the principals  relate the subject to the principals

13 UCR Unix DAC Revisited (1) ActionProcessEffective UID Real Principals User A Logs InshellUser A Load Binary “Goodie” Controlled by user B GoodieUser A? When the Goodie process issues a request, what principal(s) is/are responsible for the request? Under what assumption, it is correct to say that User A is responsible for the request? Assumption: Programs are benign, i.e., they only do what they are told to do.

14 UCR UNIX DAC Revisited (2) ActionProcessEffective UID Real Principals shellUser A Load AcroBat Reader BinaryAcroBatUser A Read File Downloaded from Network AcroBatUser A? When the AcroBat process (after reading the file) issues a request, which principal(s) is/are responsible for the request? Under what assumption, it is correct to say that User A is responsible for the request? Assumption: Programs are correct, i.e., they handle inputs correctly.

15 UCR Hierarchical Authority – compounding the problem OS is super-user – has DAC access to all processes OS Both resource manager and access control manager  Can we decouple these roles? OS exploits are deadly—full authority to access anything is obtained

16 UCR Hierarchical authority and cross-layer attacks

17 UCR What should we do instead? Other models of access control Mandatory access control: remove the discretionary part--you cannot pass on permissions  Permissions specified by the system and cannot be changed (e.g., using labels) Role based access control: permissions associated with role Still have to solve the hierarchical authority problem Security vs. usability

18 UCR Can we do this in software? Can we, at least, do better? Are there quick and dirty fixes?  Consider, SMEP/SMAP, kGuard, secvisor… Plan for today:  Eric presents CHERI: practical hardware supported capabilities  Nael overviews SELinux (software supported access control) and NIMP (hardware supported access control)

19 UCR Security Enhanced Linux (SELinux) Developed by National Security Agency (NSA) and Secure Computing Corporation (SCC) to promote MAC technologies MAC functionality is provided through the FLASK architecture Policies based on type-enforcement model Integrated into 2.6 kernels Available in most (all?) modern Linux distributions

20 UCR FLASK Flux Advanced Security Kernel Developed over the years (since 1992) in several projects: DTMach, DTOS, Fluke General MAC architecture Supports flexible security policies, “ user friendly ” security language (syntax) Separates policies from enforcement Enables using more information when making access control decisions  E.g., User ids, Domains/Types, Roles

21 UCR Type Enforcement (or Domain Type Enforcement) Type enforcement first proposed by W. E. Boebert and R. Y. Kain.  A Practical Alternative to Hierarchical Integrity Policies. In In Proceedings of the 8 National Computer Security Conference,  Aim at ensuring integrity Key Idea for Type Enforcement:  Use the binary being executed to determine access.  What do DAC and MAC use?

22 UCR Rationale of Type Enforcement (1) Integrity level should be associated with programs (rather than processes)  Trust in programs is required for integrity Examples of assured pipelines:  Labeling: All printouts of documents must have security labels corrected printed by a labeller.  Encrypting: Before sending certain data to an output channel, it must be encrypted by an encryption module Data must pass certain transforming system before going to certain outputs

23 UCR Domain-type Enforcement: High- level Idea Add a new access matrix  One row for each subject domain (more or less )  One column for each pair (object type, security class)  Each cell contains all operations the subject can perform on objects of a particular type and security class

24 UCR Domain-type Enforcement (1) Each object is labeled by a type  Object semantics  Example:  /etc/shadow etc_t  /etc/rc.d/init.d/httpd httpd_script_exec_t Objects are grouped by object security classes  Such as files, sockets, IPC channels, capabilities  The security class determines what operations can be performed on the object Each subject (process) is associated with a domain  E.g., httpd_t, sshd_t, sendmail_t

25 UCR Domain-type Enforcement (2) Access control decision  When a process wants to access an object  Considers the following: process domain, object type, object security class, operation Example: access vector rules  allow sshd_t sshd_tmp_t: file { create read write getattr setattr link unlink rename }

26 UCR Limitations of the Type Enforcement Model Result in very large policies  Hundreds of thousands of rules for Linux  Difficult to understood Using only programs, but not information flow tracking cannot protect against certain attacks  Consider for example: httpd -> shell -> load kernel module

27 UCR SELinux in Practice Theoretically, can be configured to provide high security. In practice, mostly used to confine daemons like web servers  They have more clearly defined data access and activity rights.  They are often targets of attacks  A confined daemon that becomes compromised is thus limited in the harm it can do. Ordinary user processes often run in the unconfined domain  not restricted by SELinux, but still restricted by the classic Linux access rights.

28 UCR Non-inclusive Memory Permissions Idea:  We don’t give full permissions to the OS/hypervisor  We also don’t let them manage permissions  But we need to let them manage some permissions to do their work  Specify the set of legal permission transitions

29 UCR NIMP Design