* 6 *

Access control

Fact of the week

In mathematics, an algebra is a formal system of operations with special rules. If the order in which we apply two operations A and B matters, the algebra is said to be non-commutative:
  AB (object) =/= BA (object) ????
For instance, suppose A and B are access-control matrices which act on a vector of permissions.
 A = ( 0 0 )   B = ( 1 0 )    v = ( a )
     ( 1 0 )       ( 0 0 )        ( b )

  AB v = a
  BA v = 0
Non-commutative operations can also be a model for access control, if we require credentials to be acquired in a particular order.

Chapter 3,6,7 Gollmann
So you reported to the visitors desk on arrival and obtained an identity card. Now you have to show your card at every doorway to get past the armed guards.

You're a virus trying to get into the body. You have forged your credentials by picking up a code which you found lying around on some dead cell. Now you try nervously to get past the security checks on cell walls. But even if you get in, sooner or later a security patrol is going to notice when you blow up the cell!

You are a computer virus/cracker. You've forged your way into the system by stealing the ID card of another user. Now you have access to all of the places he/she had access to. What's more, there are no security patrols looking for you! You're home and dry! The next day you walk right into the Micro-tosh building. There is not even a checkin desk. You don't need a pass! Go get it!

After we have identified ourselves to a computer system, and that identity has been scrutinized and verified, there is then the question of what privileges that identity should have to files and processes on the system.

A hierarchy of privilege

Every system must have at least one user with privileges to every part of the system. The system administrator requires these privileges in order to control the system on behalf of others. This means that the system adminisrator must have complete security clearence. The privileges conferred to others should then be less than this. In general the less privilege the less chance that accidents will lead to damage or security breaches.
OSPrivileged account

Reference monitor and MAC/DAC

The basic model for restricting privilege is to think of the resources which we are trying to protect as objects which can have certain attributes. The subject (the user) then tries to access the objects with a set of credentials based on their identity. A reference monitor stands between users and the objects. It checks the access rights, granting or denying access accordingly.
          Subject  --->  Access  ----->  Reference   ------>  Object
                         request          monitor
The monitor checks the attributes. These may tell us two things: This was one of our design principles. Usually the first of these is just a special case of the latter, e.g. giving permissions to no one prevents anyone from using an object in a certain way. For instance, the Unix execute file flag restricts what one can do with a file, independently of any restrictions on who has, say, read access to it.

Access operations: semantics and attributes

There are two basic modes of accessing objects: passive and active, i.e. read-only and read-write. These are referred to by Gollmann as Observe and Alter. The semantics of file access specify what multiple users can do with files with respect to file operations. This has to do with locking (read-only lock, or read-write locks). Look back at the operating systems course notes about locking. The integrity of files, observed by different users can be affected by these semantics. For instance, in Unix, a file can be altered by one process while another process is reading it. This can cause problems. Unix provides a solution based on Discretionary Access Control (DAC) only (the flock() function), other filesystems prevent write access to files while others are reading them forcibly, i.e. Mandatory Access Control (MAC).

In one security model, called the Bell-LaPadula model, the access permissions on files can be set differently in these two cases. We end up with a table or matrix:

             | execute | append |  read  |  write
    observe  |   X     |        |   X    |    
    alter    |         |   X    |        |    X
Most models are not this refined. The precursor to most models in use today is the historically important Multics system.

File permissions and privilege

Operating systems employ various filesystem models. Some systems have complex permission models such as Access Control Lists (ACLs) which can be difficult to understand, while others have simple but limited functionality. In practice, the complex functionality of many modern filesystems is wasted because users cannot understand how to secure their files and give up trying. Also, maintaining ACL permissions is harder and there is thus the problem that the system might become insecure because of the difficulty of maintaining file permissions.

NT model (NTFS)

The NTFS filesystem model is based on Access Control Lists. Each file is owned by a specific user. Each user may belong to any number of groups. Each file has an ACL in which access can be granted or denied to any named list of users and/or groups (i.e. we can either code a rule or an exception to a rule). The access rights of each group or user are taken from the set: Note that some of the permissions restrict functionality, while others restrict access.

Unix model

Unix introduced a simple model of file permissions in the 70's which has proven to be quite effective and easy to understand. In recent times, Unix has added a modern approach to file permissions using ACLs, but very few sites have adopted this because of the complexity.

In the original Unix model, each file has three categories of user: User (u), Group (g) and Other (o). Any user can be a member of any number of groups.

Each file has an owner and group attribute, and a set of flags

for each of the categories. Note that a limitation of this model is that a file can only be a member of one group at a time.

The main limitation of the Unix model is that ordinary users do not have the right to make their own groups. In this way, the model shoots itself in the foot. There are ways around this, but Unix has not introduced a standard solution to the problem. We can think of the Unix model as being a coarse approximation to the model of ACLs.

Other filesystems

Many other filesystems have been created at different times. The ACL model is increasingly used, but each filesystem designer seems to introduce their own flags, each with special properties. This makes them very hard to understand for inexperienced users. Other filesystems include AFS, DFS. These filesystems can be added to Unix and other systems and have security properties which are based on the idea of a world-wide filesystem. Unfortunately they are rather complex:
DFS permissions. New files inherit the initial object
ACL of their parent directory. These flags can be applied
to named lists of users, or groups or others, in the Unix sense.

 r Ability of open and read a file or
   directory contents.
 w Ability to open and write to a file or
   to add files to a directory.
 x Ability to execute files as programs
   or enter directories.
 d Ability to erase (delete) a file or
 c Ability to modify file attributes 
   including rename.
 i Ability to add files to a directory

AFS permissions. These flags can be applied
to named lists of users, or groups but not `others'.
Four shorthand forms also exist write=rlidwk,
read=rl, all=rlidwka, and none removes an entry.

 r Ability of open and read a file or 
   directory contents.
 l Lookup within a directory.
 w Ability to open and write to a file.
 i Ability to insert files in directories.
 d Ability to erase (delete) a file or
 a Ability to modify file attributes 
   including rename.
 k Lock files.

Inheritance of permissions

Also of interest to file security is the matter of what security attributes are inherited by new files. Files have to start out with some kind of permissions. Again this is an operating system dependent matter. In the list below, you should note that there are almost no pure BSD/SysV systems left. Most systems are hybrid.

Process permissions

Access rights apply not only to secondary storage but to any resource. In particular, the right to communicate with, control or request services from a process. The same basic ideas apply, but access controls usually have different attributes. Process permissions are usually set by access control lists, or on the basis of understood protocols, such as passwords, keys, or cookies (the message in a fortune cookie).

Unix processes have an owner and a group membership. These are normally inherited from the the user who starts the process and from the group attribute of the program file respectively (though see below about setuid/setgid programs). Each process has the privileges afforded to it by these labels.

Kernel: Two mode operation and protection rings

The basic security of multiuser operating systems lies in the ability to restrict privilege. One of our design criteria was to try to prevent malicious users from circumventing security mechanisms. In some operating systems this has been possible by accidental or deliberate memory corruption. Since software is often buggy, we should not rely on software to behave properly. Stronger measures are needed to protect the system. This was the idea behind two-mode operation (see the operating system course notes). By having system protection hard-coded in hardware, the system is more secure. The Multics operating system generalized this idea to more than two-modes. A series of protection levels or rings was used, each of which encapsulated the inner rings. A typical use of protection rings would be the following:
  1. Operating system kernel
  2. Operating system
  3. Utilities
  4. User processes
In Unix's two-mode operation, only rings 0 and 3 are used. This has made it easy to port Unix to a variety of architectures which support 2-mode operation (e.g PC's including and later than i386).

Role based permissions

In a dynamical, interactive situation we could generalize the notion of access to allow users different permissions depending on what they are doing. This can be done in different ways Unix setuid programs are an example where the activities of a program can be changed (by the superuser) so as to grant a specific program the right to operate with a different user-identity and thus privileges (without authentication). The setgid is a corresponding mechanism for setting the group ownership of a process. Note that setuid programs often give more privilege than is necessary and such programs have been the major cause of security problems on Unix platforms.

Service access: TCP wrappers/filters

TCP wrappers is an interface (wrapper) which grants or denies access to network services at the level of a host. It used access control lists, where the access attributes are host names or IP addresses: e.g. /etc/hosts.allow
in.fingerd: 128.39.89. 128.39.74. 128.39.75.
in.cfingerd: 128.39.89. 128.39.74. 128.39.75.
sendmail: ALL
cfd: .iu.hio.no LOCAL
in.ftpd: ALL 
ftpd: ALL
in.telnetd: LOCAL .iu.hio.no

# Portmapper doesn't understand DNS for security
portmap: 128.39.89. 128.39.74. 128.39.75.
rpc.mountd: 128.39.89. 128.39.74. 128.39.75.
rpc.nfsd: 128.39.89. 128.39.74. 128.39.75.    
On Windows 2000, the network and dialup connections control panel, one has TCP/IP filtering which is like TCP wrappers
TCP ports      |   UDP ports    |  IP protocols
Permit Only    |  Permit Only   |   Permit Only
  21           |                |   4
  80           |                |
  443          |                |

Network access: Firewalls

Routers can exact access control on datagrams, where the attributes are, amongst other things, A firewall blocks access at the network level.
For instance, Cisco IOS rules:

ip access-group 100 in
access-list     100 permit tcp host eq http
access-list     100 permit tcp any                     host eq smtp
access-list     100 deny   ip  any                     any

Modern versions of operating systems can filter IP packets in the kernel too, giving hosts effectively a host-based firewall. For instance, Linux has "IP chains":

ipchains -N newchain                               # new ACL/chain
ipchains -A newchain -p tcp -s 0/0 smtp -j ACCEPT  # -s source address
ipchains -A newchain -p tcp -s 0/0  www -j ACCEPT
ipchains -A newchain -j DENY                       # all else

The CIDR notation 0/0 is the same as, or "any". Windows 2000 has corresponding "IPSec filters". and the local security policy has an IP filter list.

Description|Protocols|Source port|Destination port|Source address|Destination address
   FTP     |   TCP   |  ANY      |       21       | Any IP       |  My IP
   HTTP    |   TCP   |  ANY      |       80       | Any IP       |  My IP

Generalized lattices

Finally, let us generalize the idea of access controls by abstracting the procedure of passing through multiple checkpoints or reference monitors.

Suppose we want to ensure that users go through a particular sequence of authentications and access controls. e.g. Think of an airport. First we go through checkin, then passport control and baggage check, then finally the boarding card is checked. It is not possible to carry out these operations in a different order, because the later parts depend on the results of the earlier parts. In some cases, it is possible to go back however, keeping credentials for going forward again.

Non-commutative access is about forcing users to go through access controls in a special order. There might not be a unique combination, but we do require a partial ordering of access controls. If we require N separate controls, then the number of ways from no-access to full-access can be drawn as an N-dimensional cube, called a lattice. N dimensions are hard to visualize, so let us suppose we have only three, labelled (x,y,z).

                          ---------   (x,y,z)
                        / |        /|
                       /  |       / |
                       ----------   |
                      |   |      |  |
                      |  / ----- |  /
                      | /        | /
                      |/         |/
The edges of the lattice show the routes from no access to full-access. Different routes through the access control system can be traced by trying to get from one corner of the cube at (0,0,0) (check-in) to the other corner at (x,y,z), which is where we wish to get to (our seat on the aircraft, for instance). We can only move along an edge of the lattice in a given direction if we have access.

Ordered access control means that we can only travel along certain edges of the lattice. Not all of them are open, it is like trying to find a route through a labyrinth to reach the destination.

This is only an abstract representation of the issue of ordered access controls, but it provides a nice way of visualizing what is involved. There is a fundamental connection between ordered lattices and matrix algebras. Try, if you can, to imagine how the lattice would work with more than three dimensions.

Thought of the week

In procedural programming there are local and global variables. In object orientation, there are called public and private objects. How does this relate to access control? How is access granted? Is there any authentication?