Authentication James Walden Northern Kentucky University Access Control

Authentication James Walden Northern Kentucky University

Access Control 1. What is Access Control? 2. Access Control Matrix Model § § § Protection State Transitions Special Rights Principle of Attenuation of Privilege 3. Groups and Roles 4. Implementation of the Access Control Matrix § § Access Control Lists: by column (object). Capabilities: by row (subject). 5. Access Control Flaws 6. Web Access Control CSC 666: Secure Software Engineering

What is Access Control? “Its function is to control which principals (persons, processes, machines, …) have access to which resources in the system— which files they can read, which programs they can execute, how they share data with other principals, and so on. ” – Ross Anderson, Security Engineering CSC 666: Secure Software Engineering

Access Control is Pervasive Application Middleware Operating System Hardware CSC 666: Secure Software Engineering

Access Control is Pervasive 1. Application Complex, custom security policy. Ex: Amazon account: wish list, reviews, CC 2. Middleware Database, system libraries, 3 rd party software Ex: Credit card authorization center 3. Operating System File ACLs, IPC 4. Hardware Memory management, hardware device access. CSC 666: Secure Software Engineering

Access Control Matrix § Precisely describes protection state of system. P Q § Sets of system states: § P: Set of all possible states. § Q: Set of allowed states, according to security policy. § P-Q: Set of disallowed states. § ACM describes the set of states Q. CSC 666: Secure Software Engineering

Access Control Matrix objects (entities) subjects o 1 … om s 1 … sn s 1 s 2 … sn Objects O = { o 1, …, om } All protected entities. Subjects S = { s 1, …, sn } Active entities, S O Rights R = { r 1, …, rk } Entries A[si, oj] R A[si, oj] = { rx, …, ry } means the subject si has rights rx, …, ry over the object oj. CSC 666: Secure Software Engineering

ACM Example Processes bash(UID=1024), passwd(UID=0) Files: . bashrc, /etc/passwd Rights: r, w, x. bashrc /etc/passwd bash rwx r rw rw passwd rwx rw rw rw CSC 666: Secure Software Engineering

Web ACM Example CSC 666: Secure Software Engineering

Copy Right § Allows possessor to give rights to another § Often attached to a right, so only applies to that right § r is read right that cannot be copied § rc is read right that can be copied § Is copy flag copied when giving r rights? § Depends on model, instantiation of model CSC 666: Secure Software Engineering

Ownership Right Usually allows possessor to change entries in ACM column. § Owner of object can add or remove rights for other subjects. § May depend on what system allows - Can’t give rights to specific (set of) users. - Can’t pass copy flag to specific (set of) users. CSC 666: Secure Software Engineering

Attenuation of Privilege Principle: Subject may not give rights it does not possess to another. § Restricts addition of rights within a system. § Usually ignored for owner - Why? Owner should have ability to recover rights on object if desired. CSC 666: Secure Software Engineering

How can we implement the ACM? Problem: scale § Thousands of subjects. § Millions of objects. § Yet most entries are blank or default. Solutions § Group subjects together as a single entities - Groups and Roles § Implement by row: Capabilities § Implement by column: Access Control Lists CSC 666: Secure Software Engineering

Groups and Roles § Collect subjects together to express: § Need to share objects. § Security categories (e. g. , admin, faculty, student, guest. ) § role: group tying membership to function. § Problem: loss of granularity. CSC 666: Secure Software Engineering

Capabilities § § Implement ACM by row. Access Control associated with subject. Example: Web authenticated session IDs. Example: UNIX file descriptors § System checks ACL on file open, returns fd. § Process subsequently uses fd to read and write file. § If ACL changes, process still has access via fd. User ls homedir rootdir james rx rw r CSC 666: Secure Software Engineering

Capability Questions 1. How to prevent user from modifying capabilities? 2. How to prevent user from copying capabilities? 3. How to revoke rights to an object? CSC 666: Secure Software Engineering

How to prevent modification? Memory protection § Capabilities are readable, but not writable. Indirection § Capability is pointer to per-process table whose access control prevents user from touching. Cryptography § Cryptographically secure checksum associated with capability and checked before usage. CSC 666: Secure Software Engineering

How to prevent user from copying? § Copying capabilities allows users to grant rights to others. § Solution: § Use indirection or cryptographic techniques from prev slide to prevent direct access. § Add copy flag to capability, as a specific right given to copy capabilities in order to give rights to other users. CSC 666: Secure Software Engineering

How to revoke rights to an object? Direct solution § Check capabilities of every process. § Remove those that grant access to object. § Computationally expensive. Alternative solution § Create a global object table. § Capabilities reference objects indirectly via their entries in the global object table. § Invalidate entry in global object table to revoke. CSC 666: Secure Software Engineering

Access Control Lists (ACLs) § Implement ACM by column. § Access control by object. § Example: UNIX ACLs § Short “rwx” user/group/other. § Long POSIX ACLs. User audit data root rw james r joe CSC 666: Secure Software Engineering

Access Control Flaws No access control § Relying on attacker not knowing URL. Client-side access control § Relying on a URL parameter like admin=true. § Relying on the Referer header. Sequence based access control § Relying on attacker accessing pages in correct sequence. CSC 666: Secure Software Engineering

Securing Access Controls Requirements § Create ACM based on roles, resources. Design § Single point of control for AC decisions. § Base AC decisions on user’s session. § Apply additional AC for admin pages, such as IP range requirements. § Use per-transaction re-authentication for high impact transactions. § Log events where sensitive data accessed. CSC 666: Secure Software Engineering

Defense in Depth Network Access Control § Prevent access to unauthorized ports. § Prevent access from unauthorized IPs. Web Server Access Control § Use web server controls to prevent access to static resources except through application. Application Access Control § Custom AC for your application. Database Access Control § Use different DB accounts for different roles. § Fine-grained AC at the row or column level. Operating System Access Control § Use least privilege accounts for application, servers. CSC 666: Secure Software Engineering

Key Points § Access Control Matrix § Implementation as capabilities or ACLs. § Common Flaws § No AC or relying on client-side AC. § Defense in Depth § AC at Network, Server, App, DB, and OS. CSC 666: Secure Software Engineering

References 1. Matt Bishop, Computer Security: Art and Science, Addison-Wesley, 2005. 2. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007. 3. PCI Security Standards Council, PCI DSS Requirements and Security Assessment Procedures, v 1. 2, 2008. 4. Dafydd Stuttart and Marcus Pinto, The Web Application Hacker’s Handbook, Wiley, 2008. CSC 666: Secure Software Engineering