Access Control Mechanisms

Access Control Lists

A variant of the access control matrix is to store each column with the object it represents. Thus each object has associated with it a set of pairs, with each pair containing a subject and a set of rights. The named subject can access the associated object using any of those rights. Defn : Let S be the set of subjects, and R the set of rights, of a system. An access control list (ACL) L is a set of pairs L={(s, r):s S, rR. Let ACL be a function that determines the access control list L associated with a particular object O. The interception of the access control list ACL(O)={(si, ri):1 I n Example : Consider the access control matrix
Process1 Process2 File1 Read,write,own append File2 Read Read,own Process1 Read,write,own,execute Read Process2 write Read,write,own,execute

ACL(file1) = { (process1, {read, write, own}), (process2, {append}) } ACL(file2) = { (process1, {read}), (process2, ({read, own}) } ACL(process1)={(process1,{read, write, execute, own}),(process2,{read})} ACL(process2)={(process1,{write}),(process2,{read, write, execute, own})} Each subject and object has an associated ACL. Process1 owns file1, can read, write to it; process2 can only append to file1. Process2 owns file2; both processes can read file2. Both processes can write to process2. If the subject is not named in the ACL, it has no rights over the associated object. On a system with many subjects, the ACL may be very large. If many subjects have the same rights over the file, one could define a wildcard to match any unnamed subjects, and give them default rights. Abbreviations of Access Control Lists Some systems abbreviate the ACL such as file access control in Unix which divides the set of users into three classes namely, the owner of the file, the group owner of the file and all other users. Unix OS provide read, write and execute access rights represented as three triplets. The first is the owner rights, the second is group rights and the third, others rights ( rw-r--r--). Creation and maintenance of access control lists

Specific implementations of ACLs differ in details, some of the issues are: 1. Which subjects can modify an objects ACL 2. If there is a privileged user (such as root in Unix), does the ACLs apply to that user. 3. Does the ACL support groups of wildcards. 4. How are contradictory access control permissions handled?. If one entry grants read privileges only and another grants write privileges only, which right does the subject have over the object? 5. If a default setting is allowed, do the ACL permissions modify it, or is the default used only when the object is not explicitly mentioned in the ACL? Which subjects can modify an objects ACL When an ACL is created, rights are instantiated. Chief among these rights is the one we will call own. Processors of the own right can modify the ACL. Creating an object also creates its ACL, with some initial value (possibly empty, but usually the creator is initially given all rights, including own, over the new object). By convention the subject with own rights is allowed to modify the ACL. Do the ACLs apply to a privileged user? Many systems have user with extra privileges. The root/super-user on Unix system and the administrator on Windows NT and 2000 systems are such users. ACLs are applied in a limited fashion to such users. Does the ACL support groups of wildcards ACLs do not or the other of the lists processes to Conflicts A Conflict arises when two access control list entries in the same ACL give different permissions to the subject. The system can allow access if any entry would give access, deny access if any entry would deny access, or apply the first entry that matches the subject. If any entry in an AIX ACL denies access, the subject is denied access regardless of the location of the entry. Otherwise if any entry has granted support groups and wildcards. In practice, systems support one (or both) to limit the size of the ACL and to make manipulation easier. A group can either refine the characteristics of the be allowed to access or be a synonym for a set of users.

access, the subject is granted access. This is an example of denial taking precedence. Cisco routers apply the first access control list entry that matches the incoming packet. If none applies the incoming packet is discarded. This is an example of the second approach. ACLs and Default Permissions When ACLs and abbreviations of access control list or default access rights coexist (as in many Unix systems), there are two ways to determine access rights. The first is to apply the appropriate ACL entry if one exists, and to apply the default permissions or abbreviations of access control list otherwise. The second way is to augment the default permissions or abbreviations of access control lists with those in the appropriate ACL entry. Revocation Rights Revocation or the prevention of a subjects accessing an object, requires that the subjects rights be deleted from the objects ACL. Preventing a subject from accessing an object is simple. The entry for the subject is deleted from the objects ACL. If only specific rights are to be deleted, they are removed from the relevant subjects entry in the ACL. If ownership does not control the giving of rights, revocation is more complex. Example : Windows NT Access Control Lists Windows NT provides access control lists for those files on NTFS partitions. Windows NT allows a user or group to read, write, execute, delete, change the permissions of, or take ownership of a file or directory. These rights are grouped into commonly assigned sets called generic rights. The generic rights for files are as follows. No access : Subject cant access the file Read : The subject can read and execute the file Change : The subject can read, execute, write or delete the file Full control : The subject has all the rights to the file. In addition, the generic right special access allows the assignment of any of the six permissions. Windows NT directories also have their own notion of generic rights.

No access : The subject cant access the directory Read : The subject can read and execute the files within the directory List : The subject can list the contents of the directory and may change to a subdirectory within that directory Add : The subject may create a file or subdirectory in the directory Add and Read : Combines the generic rights add and read Change : The subject can create, read, execute, or write files within the directory and can delete the subdirectories Full Control : The subject has all rights over the files and subdirectories in the directory

Capabilities
Capability is like the row of an access control matrix. Each subject has associated with it a set of pairs, with each pair containing an object and a set of rights. The subject associated with this list can access the named object in any of the ways indicated by the named rights. Defn : Let O be the set of objects, and R the set of rights, of a system. A capability list C is a set of pairs C={(o, r): o O, r R}. Let CAP be a function that determine the capability list C associated with a particular subject s. The interpretation of the capability list CAP(s)={oi, ri): 1i n } is the subject s may access oi using any right in ri. CAP(process1) = { (file1, {read, write, own}), (file2, {read}), (process1, {read, write, execute, own}), (process2, {write})} CAP(process2) = { (file1, {append}), (file2, {read, own}), (process1, {read, }), (process2, { read, write, execute, own })} Each subject has associated CAP list. Thus process1 owns file1, and can read or write to it; process1 can read file2; process1 can read, write to, or execute itself and owns itself; and process1 can write to process2. Similarly process2 can append to file1; process2 owns file2 and can read it. Process 2 can read process1; and process2 can read, write to, or execute itself and owns itself. Implementation of Capabilities Three mechanisms are used to protect capabilities : Tags, Protected Memory and Cryptography Tags : A tagged architecture has a set of bits associated with each hardware word. The tag has two states: set and unset. If tag is set, an ordinary

process can read and modify the word. Further, an ordinary process cant change the state of the tag; the process must be in a privileged to do so. Protected Memory : More common is to use the protection bit associated with the paging or segmentation. All capabilities are stored in a page(segment) that the process can read but not alter. This requires no special purpose hardware other than that used by the memory management scheme. But the process must reference capabilities indirectly, usually through pointers, rather than directly. Cryptography : The goal of the tags and memory protection is to preventing the capabilities from being altered. This is like integrity checking. Cryptographic checksums are another mechanism for checking the integrity of information. Each capability has a cryptographic checksum associated with it, and the checksum id digitally encrypted using a cryptosystem whose key is known to the operating system. When the process presents a capability to the operating system, the system first recomputes the checksum associated with the capability. It then either encrypts the checksum using the cryptographic key and compares it with the one stored in the capability, or decrypts the checksum provided with the capability and compares it with the computed checksum. If they match, the capability is unaltered, if not the capability is rejected. Copying and Amplifying Capabilities The ability to copy capabilities implies the ability to give rights. To prevent processes from indiscriminately giving away rights, a copy flag is associated with capabilities. A process cant copy a capability to another process unless the copy flag is set. If the process does copy the capability, the copy flag may be turned off (at the discretion of either the process or the kernel). Amplification is the increasing of privileges. The idea of modular programming, especially of abstract data types requires that the rights of a process has over an object be amplified. Revoking of Rights In a capability system, revoking access to an object requires that all the capabilities granting access to that objects be revoked. Conceptually each process could be checked and the capabilities deleted. The cost of such an operation would be unacceptable, hence alternative methods are used.

The simplest mechanism is indirection. Define one or more global object tables. In this scheme each object has a corresponding entry in a table. Capabilities do not name the object directly, they name the entry in the table corresponding to the object. This scheme has several advantages. To revoke capabilities, the entry in the global object table is invalidated. Then any references will obtain an invalid table entry and will be rejected. If only some of the capabilities are to be revoked, the object can have multiple entries, each corresponding to a different set of rights or a different group of users. An alternative revocation mechanism uses abstract data type managers. Included with each abstract data type is a revocation procedure. When the access is to be revoked, the type manager simply disallows further access by the subject whose rights are being revoked. This does not affect alternative method of accessing the objects underlying the abstract data types. For example access to a file may be revoked, but this technique would not block access to the underlying segments through an alternative type manager. Limits of Capabilities Problems if you dont control copying of capabilities

A (High)

C-List
R*Design

A (High)

C-List
R*Design RW*Design

Design(Low)
RW*Design

Design(Low)
RW*Design

B (Low) C-List
RW*Design

B (Low) C-List
RW*Design

B has the capability to read and write the file Design which he copies to the file design, and A has the capability to read (copies) the file Design capability; now A has added its capability and can write to Design file, violating the *-property!

Remedies Label capability itself Rights in capability depends on relation between its compartment and that of object to which it refers In example, as capability copied to High, and High dominates object compartment (Low), write right removed Check to see if passing capability violates security properties In example, it does, so copying refused Distinguish between read and copy capability Take-Grant Protection Model does this (read, take)

Comparison with Access Control List Two questions underlie the use of access controls: 1. Given a subject, what objects can it access, and how? 2. Given a Object, what subjects can it access, and how? In theory either access control lists or capabilities can answer the question. For the first question, capabilities are the simplest, just list the elements of the subjects associated C-List. For the second question, ACLs are the simplest, just list the elements of the objects access control list. In an ACL based system answering the 1st question requires all the objects to be scanned. The system extracts all ACL entries associated with the subject in question. In a capability based system, answering the 2nd question requires all subjects to be scanned. The system extracts all capabilities associated with the object in question.

Locks and Keys

The locks and keys technique combines features of access control lists and capabilities. A piece of information (the lock) is associated with the object and a second piece of information (key) is associated with those subjects authorized to access the object and the manner in which they are allowed to access the object. When the subject tries to access the object, the subjects set of keys is checked. If the subject has a key corresponding to any of the objects locks, access of the appropriate type is granted. The difference between locks and keys and the other access control mechanism is the dynamic nature of the former. An access control list is static in the sense that all changes to it are manual; a user or process must interact with the list to make the change. Locks and keys on the other hand

may change in response to system constraints, general instructions about how entries are to be added, and any factors other than a manual change. Type Checking Type checking restricts access on the basis of the types of the subject and object. It is a form of locks and keys access control, the piece of information being the type. Systems use type checking in areas other than security. The simplest case of type checking is distinguishing Instructions (Commands) from data. The operation execute can be performed only on Instructions (Commands) and the operations read and write can be performed only on data. Many systems enforce this distinction. Strictly enforced type checking is a powerful protection mechanism. The DTEL policy language and the supporting domain and type enforcement (DTE) mechanism are good examples.

Ring-Based Access Control

The multics system generalizes the notion of a supervisor and user state with a protection mechanism called ring based access control. To understand its simplicity and elegance, one must realize that the files and memory are treated the same from the protection point of view. For example a procedure may occupy a segment of a disk. When invoked, the segment is mapped into memory and executed. Data occupies other segments on disk, and when accessed, they are mapped into memory and accessed. In other words there is no conceptual difference between a segment of memory and a segment on a disk. Segments are of two kinds: data and procedure. A segment could have r (read) rights, w (write) rights, e (execute) rights, and a (append) rights associated with it. These rights are contained in access control list, which constrain access on a per user basis. So all procedures that user B executes would have the rights associated with that user B. In addition Multics system defines a sequence of protection rings numbered from 0 to 63. The kernel resides in ring 0. The higher the number, the lower the privileges of the segments in that ring. We also say that a procedure executes in ring r because the ring is associated with the individual segment, not with the entire process.

Subject to the access constraints noted below, procedures can cross ring boundaries. In some cases the crossing causes a ring cross fault that traps to the kernel. At that point a mechanism called the Gatekeeper checks arguments and access and performs other functions that constrain ring crossings. In other cases, no ring crossing fault is induced, and access is permitted if the access modes allow. A gate is simply an entry point (like the public designators of objects oriented languages). Gates are specially declared within programs, and the compiler and linker generate special code to make these entry points vulnerable to other procedures. Assume that a procedure executing in ring r wants to access a data segment. Associated with each data segment is a pair of ring numbers called an access bracket(a1, a2), with a1 a2. Assume that the data segments permissions allow the desired access. The ring numbering adds an extra constraint. r a1 : access permitted. But a ring crossing fault occurs a1<r a2 : r and e access permitted; w and a access denied a2 < r : all access denied

Assume that the same procedure, again executing in ring r, wants to access a procedure segment. Each procedure segment has an access bracket, just like a data segment. A procedure segment may also have a call bracket (c1, c2), with c1 c2. By convention, when a call bracket is present, c1 = a2, leading to an alternative notion of (a1, a2, a3), where (a1, a2) is the access bracket and (a2, a3) is the call bracket (that is c2 = a3). The rules for access differ slightly from those for accessing a data segment. r a1 : access permitted. But a ring crossing fault occurs a1 r a2 : all access permitted; and no fault occurs a2<r a3 : access permitted if made through a valid gate a2<r : all access denied

Propagated Access Control List

Propagated Access Control List (PACL) mechanism provides the creator of an object with control over who can access the object. It is an implementation that is ideal ORCON policy. The creator(originator) is kept with the PACL and only the creator can change the PACL. When a subject reads an object, the PACL of the object is associated with the subject. When
The

a subject creates an object, the PACL of the subject is associated with the object. The notion PACLsubject means that the subject is the originator of the PACL. Only subject can change that PACL. The notion of PACL(entity) is the PACL associated with the entity. Ex: A creates the file dates. A wants to control who can read the file. The files PACL is the PACL associated with A: PACL(dates) = PACLA Let the PACL of an object O be PACLS When another subject S reads O, PACL(O) must augment PACL(S). Otherwise, S could create another subject O, and copy the data from O to O. Then S would have no control over the data in O, defeating the purpose of using PACL. Hence an object can have PACLs associated with two creators. If so, both creators control access to the object. Only subjects common to both PACLs can access the object. Otherwise, one creator would not control access to the data it expects to control. The default is to deny access unless both creators allow it.