Access Control/Capabili1es

Transcription

1 Access Control/Capabili1es Some slides/ideas adapted from Ninghui Li 1

2 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 2

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

4 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." 4

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

6 Analysis of The Confused Deputy Problem UCR 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 6

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

8 ACCESS MATRIX MODEL Objects (and Subjects) F G S u b j e c t s U V r w own r r w own rights 8

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

10 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 10

11 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 11

12 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 UCR Challenging to fill the gap between the subjects and the principals relate the subject to the principals 12

13 Unix DAC Revisited (1) Action Process Effective UID Real Principals User A Logs In shell User A User A Load Binary Goodie Controlled by user B Goodie User 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. 13

14 UNIX DAC Revisited (2) Action Process Effective UID Real Principals shell User A User A Load AcroBat Reader Binary AcroBat User A User A Read File Downloaded from Network AcroBat User 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. 14

15 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 15

16 Hierarchical authority and cross-layer acacks 16

17 What should we do instead? Other models of access control Mandatory access control: remove the discre1onary 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 S1ll have to solve the hierarchical authority problem Security vs. usability 17

18 Can we do this in solware? Can we, at least, do becer? Are there quick and dirty fixes? Consider, SMEP/SMAP, kguard, secvisor Plan for today: Nithin presents Hyperwall Nael presents NIMP: finer-grained mandatory access control Nael overviews SELinux (solware supported access control) possibly next Nme? Nael presents CHERI: pracncal hardware supported capabilines (next Nme) 18

19 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 19

20 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 20

21 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? 21

22 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 22

23 Domain-type Enforcement: Highlevel 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 23

24 Domain-type Enforcement (1) Each object is labeled by a type Object semanncs Example: /etc/shadow etc_t /etc/rc.d/init.d/htpd htpd_script_exec_t Objects are grouped by object security classes Such as files, sockets, IPC channels, capabilines The security class determines what operanons can be performed on the object Each subject (process) is associated with a domain E.g., htpd_t, sshd_t, sendmail_t 24

25 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 } 25

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

27 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. 27

28 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 transinons 28

29 NIMP Design 29