CSE361 Web Security. Access Control. Nick Nikiforakis

CSE361 Web Security Access Control Nick Nikiforakis nick@cs.stonybrook.edu

Access Control: introduction How do we protect our confidential data from unauthorized usage? Two important cases: An attacker has access to the raw bits representing the information need for cryptographic techniques There is a software layer between the attacker and the information => access control techniques 2

Access Control (Authorization) Limiting access to sensitive resources Informally Who can access what and in what way? Application Middleware Operating System Hardware 3

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

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

Access Control Matrix As system changes, state changes. State transitions. Only concerned with protection state. ACM must be enforced by a mechanism that limits state transitions to those that go from one element of Q to another. 6

subjects ACM Description s 1 s 2 s n objects (entities) Objects O = { o 1,,o m } All protected entities. o 1 o m s 1 s n Subjects S = { s 1,,s n } Active entities, S O Rights R = { r 1,,r k } Entries A[s i, o j ] R A[s i, o j ] = { r x,, r y } means subject s i has rights r x,, r y over object o j 7

Example: File/Process Processes p, q Files f, g Rights r, w, x, a, o f g p q p rwo r rwxo w q a ro r rwxo 8

Free text to ACM Alice, who owns file1, trusts Bob to read and write that particular file. Bob, on the other hand, is afraid that Alice will edit his files so he only allows her to read file2, but nothing more. Steve, who no one trusts, has made a program called prog1 who he wants others to execute, but not modify. Lastly, everyone but Bob, can read Joe s diary. 9

Ownership Right Usually allows possessor to change entries in ACM column So owner of object can add, delete rights for others 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 10

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 gives herself rights, gives them to others, deletes her rights. 11

How can we implement the ACM? Problem: scale Thousands of subjects. Millions of objects. Yet most entries are blank or default. Solutions Implement by column: Access Control Lists Implement by row: Capabilities Group users together in a flat or hierarchical model 12

Access Control Lists (ACLs) Implement ACM by column. Access control by object. Example: UNIX ACLs Short rwx user/group/other. Long POSIX ACLs. ACL is stored close to the object User root alice bob audit data rw r 13

Some ACL Questions 1. Which subjects can modify an object s ACL? 2. Do ACLs apply to privileged users? 3. How can a subject s rights be revoked? 4. What are the default permissions? 14

Which subjects can modify an ACL? Create an own right for an ACL. Only subjects with own right can modify ACL. Creating an object also creates object s ACL. Usually creator given own right at this time. Other default rights may be set at creation too. 15

Do ACLs apply to privileged users? Many systems have privileged users. UNIX: root. Windows NT: administrator. Should ACLs apply to privileged users? Need read access to all objects for backups. What security problems are produced by ignoring ACLs for privileged users? 16

How are rights revoked? Removal of subject s rights to object. Delete entries for subject from ACL. If ownership doesn t control granting rights, matters can be complex: If A has granted rights to B, what should happen to B s rights if you remove A s rights? Removal of subject s rights to all objects. Very expensive (millions of objects.) Why isn t disabling subject s account sufficient? 17

What are the default permissions? Interaction of ACLs with base permissions. POSIX ACLs modify UNIX base permissions. How are default ACLs determined? Subject Subject sets default permissions, like UNIX umask. Inheritance Objects in hierarchical system inherit ACLs of parent object. Subjects inherit sets of default permissions from their parent subjects. 18

Capabilities Implement ACM by row, instead of by column Access Control associated with subject. 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 alice rx rw r 19

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

How to prevent user from modifying? 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. 21

How to prevent user from copying? Copying capabilities allows users to grant rights to others. Solution: Use indirection or cryptographic techniques from previous 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. 22

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

ACLs vs Capabilities ACLs Slow: OS has to read ACL for each object accessed. Easy to find/change rights on a particular object. Difficult to revoke privileges for a specific subject. Capabilities Fast: OS always knows subject identity. Easy to find/change rights on a particular subject. Difficult to revoke privileges to a subject object. 24

Discretionary Access Control Discretionary Access Control, or DAC, refers to a scheme where users are given the ability to determine the permissions governing access to their own files. DAC typically features the concept of both users and groups, and allows users to set accesscontrol measures in terms of these categories. In addition, DAC schemes allow users to grant privileges on resources to other users on the same system. 25

Concept: Reference monitor Which ever system we use to represent the Access Control Matrix, we still need a piece of code that will read that representation and enforce it Reference monitor: the part of systems that enforces access control decisions 3 properties: Complete mediation: must always be called Tamper proof: adversary cannot influence it Small: Easy to verify its correctness 26

Mandatory Access Control Mandatory access control is a more restrictive scheme that does not allow users to define permissions on files, regardless of ownership. Instead, security decisions are made by a central policy administrator. Each security rule consists of a subject, which represents the party attempting to gain access, an object, referring to the resource being accessed, and a series of permissions that define the extent to which that resource can be accessed. 27

3 Formal MAC Examples Bell La Padula model for the confidentiality of data Biba model for the integrity of data Chinese wall model for protecting the confidentiality (and integrity) of data from conflict of interest 28

Bell-LaPadula Model: A MAC Model for Achieving Multi-level Security Introduced in 1973 Air Force was concerned with security in timesharing systems Many OS bugs Accidental misuse Main Objective: Prevent read access to objects at a security classification higher than the subject s clearance Enable one to formally show that a computer system can securely process classified information 29

Security Goal of BLP There are security classifications or security levels Users/principals/subjects have security clearances Objects have security classifications Example Top Secret Secret Confidential Unclassified In this case Top Secret > Secret > Confidential > Unclassified Security goal (confidentiality): ensures that information do not flow to those not cleared for that level 30

Bell-LaPadula 31

Approach of BLP Use state-transition systems to describe computer systems Define a system as secure iff. every reachable state satisfies 3 properties simple-security property, *-property, discretionarysecurity property Prove a Basic Security Theorem (BST) so that one can prove a system is secure by proving things about the system description 32

Preliminary rules L(S): Security clearance of Subject S L(O):Security classification of object O Eg. L( Thomas ) = Top Secret L( Document1 ) = Secret 33

Preliminary rules Simple Security Property, preliminary version: S can read O, iff L(O) <= L(S) and S has discretionary read access to O Rule known as No read up This rule, by itself, allows for leakage of information towards lower levels of clearance E.g. Someone with a top secret clearance reads a top secret file, and writes the contents to a classified file, where it can then be read by users with classified clearance 34

Preliminary rules *-Property, Preliminary version: Subject S can write Object O iff L(S) <= L(O) and has discretionary write access to O Rule known as No write down Together, the two rules enforce the desired information flow. 35

Need-to-know principle Even if someone has all the necessary official approvals (such as a security clearance) to access certain information they should not be given access to such information unless they have a need to know: that is, unless access to the specific information necessary for the conduct of one's official duties. The security model can be expanded to include this notion, through the use of categories (sometimes called compartments) Levels={top secret, secret} Categories={army,navy} These together create a lattice 36

An Example Security Lattice Top Secret, {army, navy} Top Secret, {army} Top Secret, {navy} Secret, {army, navy} Top Secret, {} Secret, {army} Secret, {navy} Secret, {} 37

One more definition The security level (L,C) dominates the security level (L,C ) iff L <= L and C C When considering the subset condition, don t forget that the empty set is a subset of any other set Let s rewrite the security rules of BLP using the concept of domination 38

BLP Simple Security Property: A subject S can read an object O iff S dominates O and S has discretionary read access to O *-Property: A subject S can write an object O iff O dominates S and S has discretionary write access to O The two together: No read up, no write down 39

BLP Example George has clearance (SECRET, {NUC,EUR}) DocA has clearance (CONFIDENTIAL, {NUC}) DocB has clearance (SECRET, {EUR,US}) DocC has clearance (SECRET,{EUR}) George dominates DocA CONFIDENTIAL <= SECRET & {NUC} {NUC,EUR} George does not dominate DocB {EUR,US} {NUC,EUR} George dominates DocC SECRET <= SECRET & {EUR} {NUC, EUR} 40

First limitation The BLP model, as it stands right now, does not allow a higher-ranked subject to communicate with a lower-ranked object Sometimes it is necessary Solution: Differentiate between current clearance level L c (S) and maximum clearance level L m (S) E.g. A top-secret-clearance subject can choose to lower her clearance-level to temporarily speak with a lower-clearance subject Rule: Maximum level must dominate Current level 41

Second limitation How about declassifying documents? We should be able to remove the top-secret portion of a top-secret document and give it to a subject with a secret security clearance Solution: Trusted subjects These subjects are trusted to remove sensitive information of their level and are not restricted by the *-property 42

One more problem Security objective of multilevel security in general, BLP in particular high-classified information cannot flow to low-cleared users Overt channels of information flow read/write an object These are covered in BLP Covert channels of information flow communication channel based on the use of system resources not normally intended for communication between the subjects (processes) in the system 43

3 Formal MAC examples Bell La Padula model for the confidentiality of data Biba model for the integrity of data Chinese wall model for protecting the confidentiality (and integrity) of data from conflict of interest 44

Biba Integrity Model Biba Integrity model In this model, we care about integrity of information, not confidentiality Thus, if we want confidentiality, we need to combine it with another mechanism Biba is called the dual of BLP That s because the rules seem to be opposite from BLP 45

Biba rules I(S): Integrity of subject S I(O):Integrity of object O Simple integrity property: Subject S can read object O, iff I(S) <= I(O) Rule known as, No Read Down Integrity *-property: Subject S can write to object O, iff I(O) <= I(S) Rule known as, No Write Up 46

Meaning of rules A subject can read objects at it s own integrity levels or above (opposite from BLP) Do not taint the subject s integrity by reading data with lower integrity A subject can only write at it s own integrity level or below (opposite from BLP) Do not taint the integrity of high-integrity data by allowing a lower-integrity subject to write them 47

Windows Integrity Mechanism Windows Vista introduced a Biba-like integrity mechanism to limit the ability of malware to spread into the rest of the system Process (and files created by them) have integrity labels A process with a low integrity level cannot interact with a process of medium/high integrity level All files, by default, get medium integrity label Internet Explorer (and other browsers), as well as their downloaded files, get a low integrity label Need user action to elevate it 48

Integrity Checks in action 49

3 Formal MAC examples Bell La Padula model for the confidentiality of data Biba model for the integrity of data Chinese wall model for protecting the confidentiality (and integrity) of data from conflict of interest 50

Conflict of Interest A consultant is offering her services to Bank of America and as such has access to certain confidential information, necessary for the task at hand. It would be a breach of confidentiality for her to also consult for Chase. A simultaneous contract with Delta (the airlines) is not a conflict. 51

Chinese Wall model The security policy builds on the following: Objects e.g. files. Objects contain information for only one specific company Company Dataset (CD) Collect all objects concerning one specific company Conflict-of-interest (COI) class cluster the company groups of competing (and thus conflicting) companies {Toyota, Ford, Volkswagen} {Bank of America, Chase, TD Bank} {McDonalds} 52

Chinese Wall model (Chinese Wall) Simple Security Rule: Subject S can read object O iff any of the following conditions hold: 1. There is an object O such that S has accessed O and CD(O ) = CD(O) 2. For all objects O, O PR(S) => COI(O ) COI(O) 3. O is a sanitized object Containing only public information Set of objects that a subject has read in the past 53

Chinese Wall model (Chinese Wall) *-Property: A subject S may write to object O iff both of the following conditions hold: 1. The Chinese Wall Simple Security condition allows S to read O 2. For all unsanitized objects O to which S has (or has had) access, S can read O => CD(O ) = CD(O) In other words, there should exist no unsanitized objects that can be accessed and belong to a different Company Dataset 54

Role-Based Access Control The role-based access control (RBAC) model can be viewed as an evolution of the notion of group-based permissions in file systems. Non-DAC model Middle of the road between MAC and DAC An RBAC system is defined with respect to an organization, such as company, a set of resources, such as documents, print services, and network services, and a set of users, such as employees, suppliers, and customers. 55

RBAC Components A user is an entity that wishes to access resources of the organization to perform a task. A role is defined as a collection of users with similar functions and responsibilities in the organization. Examples of roles in a university may include student, alum, faculty, dean, staff, and contractor. In general, a user may have multiple roles. A permission describes an allowed method of access to a resource. Fine grained all the way to coarse grained. E.g. read a file vs. open a new account A session consists of the activation of a subset of the roles of a user for the purpose of performing a certain task. For example, a laptop user may create a session with the administrator role to install a new program. Sessions support the principle of least privilege. 56

Hierarchical RBAC In the role-based access control model, roles can be structured in a hierarchy similar to an organization chart. More formally, we define a partial order among roles by saying that a role R1 inherits role R2, which is denoted R1 > R2, if R1 includes all permissions of R2 and R2 includes all users of R1. When R1 > R2, we also say that role R1 is senior to role R2 and that role R2 is junior to role R1. For example, in a company, the role manager inherits the role employee and the role vice president inherits the role manager. Also, in a university, the roles undergraduate student and graduate student inherit the role student. 57

Visualizing Role Hierarchy 58

RBAC in Joomla 59

Constrained RBAC Constrained RBAC allows for defined relationships among roles and conditions related to roles. Types of constraints Mutually exclusive roles User can be assigned only to one role in a set, either statically or during a session Increase the difficulty of collusion to thwart security policies Cardinality Limits (in terms of maximums) with respect to roles Maximum number of users assigned to a role, maximum number of roles assigned to one user, etc. Prerequisite roles Users can be assigned to some roles only if they are already assigned other roles E.g. in order to get the role of senior engineer you must already 60 have the role junior engineer

Attribute-based Access Control Attribute-based Access Control (ABAC) is more recent than the access control schemes we have looked at so far Access rights are granted to users through policies that combine many attributes together Attributes can be based: On the subject trying to perform the access On the object being accessed On the environment over which the access is happening 61

ABAC Scheme Image source: http://www.axiomatics.com/attribute-based-access-control.html 62

Example Online streaming service, streaming movies to registered users for a monthly fee Movie Rating Users Allowed to Stream R Age 17 and older PG-13 Age 13 and older G Everyone 63

Example continued In RBAC, we would need three roles Adult, Juvenile, Child and three permissions Can view R-rated Can view PG-13-rated Can view G-rated The administrator would have to manually assign users to roles and permissions to roles 64

Example continued In ABAC, we can instead use attributes of the users and movies to make access control decisions R1: can_access(u,m,e) <- (Age(u) 17 AND Rating(m) {R, PG-13, G}) OR (Age(u) 13 AND Age(u) < 17 AND Rating(m) {PG-13, G}) OR (Age(u) < 13 AND Rating(m) {G}) We can easily expand the above to add premium membership and promotional periods Time, Date, Country of users are all Environment attributes The same would be very cumbersome in RBAC 65

UNIX Access Control Model UID integer user ID UID=0 is root GID integer group ID Users can belong to multiple groups Objects have both a user + group owner. System compares object UID with EUID. EUID identical except after su or SETUID. 66

UNIX File Permissions Three sets of permissions: User owner Group owner Other (everyone else) Three permissions per group read write execute UID 0 can access regardless of permissions. Files: directories, devices (disks, printers), IPC 67

UNIX File Permissions Best-match policy OS applies permission set that most closely matches. You can be denied access by best match even if you match another set. Directories read = listing of directory execute = traversal of directory write = add or remove files from directory 68

Special File Permissions Each object has set of special permission bits sticky setuid setgid On a directory, means users can only delete files that they own Execute program with EUID = owner s UID Execute program with EGID = owner s GID On directories, causes default group owner to be that of directory owner s GID. 69

Changing Permissions: chmod Set specifiers u = user g = group o = other Permissions r = read w = write x = execute # remove other access chmod o-rwx *.c # add group r/w access chmod g+rw *.c # allow only you access chmod u=rwx * 70

Octal Permission Notation Each set (u,g,o) is represented by an octal digit. Each permission (r,w,x) is one bit within a digit. ex: chmod 0644 file u: rw, g: r, o: r ex: chmod 0711 bin u: rwx, g: x, o: x 4 read setuid 2 write setgid 1 execute sticky 71

Changing Ownership newgrp Group owner of files is your default group. Changes default group to another group to which you belong. chgrp Changes group owner of existing file. Only root can use this command chown Changes owner of existing file. Only root can use this command. 72

Default Permissions: umask Determines permissions given to newly created files Three-digit octal number Programs default to 0666 Umask modifies to: 0666 & ~umask ex: umask=022 => file has mode 0644 ex: umask=066 => file has mode 0600 73

setuid/setgid Solution to UNIX ACLs inability to directly handle (user, program, file) triplets. Process runs with EUID/EGID of file, not of user who spawned the process. Follow principle of least privilege create special user/groups for most purposes Follow principle of separation of privilege keep setuid functions/programs small drop privileges when unnecessary 74

Limitations of Classic ACLs ACL control list only contains 3 entries Limited to one user. Limited to one group. Root (UID 0) can do anything. 75

POSIX Extended ACLs Supported by most UNIX/Linux systems. Slight syntax differences may exist. getfacl setfacl chmod 600 file setfacl -m user:jake:r-- file File unreadable by other, but ACL allows jake 76

Immutable Files Immutable Files on Linux chattr +i Cannot delete, rename, write to, link to Applies to root too Only root can add/remove immutable flag (Ubuntu) Use lsattr to identify what flags are set on any given file 77

Host-based Access Control /etc/hosts.allow and /etc/hosts.deny used by tcpd, sshd, other servers Identify subjects by hostname IP address network address/mask Allow before Deny use last rule in /etc/hosts.deny to deny all 78

SQL Access Control Subjects Users. Roles. create role faculty grant faculty to jake Objects Databases, tables, table columns. Rights Select, insert, update, delete, references, grant. 79

SQL Access Control The grant command gives access to a user GRANT SELECT ON students TO jake or a role: GRANT SELECT, INSERT, UPDATE ON grades TO faculty and includes power to grant options: GRANT INSERT ON students TO registrar WITH GRANT OPTION The revoke command removes access REMOVE INSERT ON grades FROM faculty 80

Why is Access Control hard? Complex Objects Identifying objects of interest. Is your choice of objects too coarse or fine-grained? Inheritance in Hierarchical structures like filesystem Subjects are Complex Identifying subjects of interest. What are the relationships between subjects? Access Control states change. Security objectives often unclear. 81

Summary 1. Access Control: Center of gravity of security; pervasive. 2. Access Control Matrix simplest abstraction mechanism for representing protection state. 3. ACM is too big, so real systems typically use either: 1. ACLs: columns (objects) of ACM. 2. Capabilities: rows (subjects) of ACM. 4. Formal MAC systems, RBAC, ABAC 5. Access Control in Practice: UNIX. 82

Credits Slides based on James Walden slides on Access Control 83