Design for the RBAC NFS server

Before we can make an access control decision, the identity of the principal requesting the operation must be established. In a secure system, strong authentication should be used. More specifically, many implementations of RPC (upon which NFS is built) can be run ``secure'', meaning that RPC datagrams are strongly authenticated. However, the NFS specification ([Sun89]) does not define the permission checking to be used by servers.

In our demonstration implementation, we have not addressed the issue of strong authentication, instead we use the AUTH_UNIX style authentication that is used by default in most RPC implementations. In the future our implementation can easily be modified to make use of other forms of authentication. Another issue that we have not addressed in this demonstration is the fact that in spite of proper authentication and access control mechanisms, an intruder might still be able to obtain access to communications that pass over a network. In the case of NFS, data transferred over the network is not normally encrypted, so an eavesdropping intruder may read any file read or written using NFS just by monitoring the traffic. An active intruder might also attempt to modify the information passing through the network. To guard against these threats, additional measures, such as IP-level encryption (see section 7.1), are necessary.

Using AUTH_UNIX style of authentication, the server receives with each request the effective user and group identities (UID and GID respectively) of the caller. During normal operations, these identities are used when the server makes file accesses. However, the main responsibility for access control still rests with the kernel of the client that allows or disallows access based on the file attributes of a file, as reported by the NFS server.

  
Figure 5.2: Main components of the RBAC NFS server

Figure 5.2 shows the main components of our NFS server implementing role-based access control. The central idea of our design is to mount the remote file system as usual but then to side-step the default permission checking behavior. The numbers in the figure show a typical flow of events.

1. A user starts out by using a special application to activate one or more roles. This application communicates with the role state monitor module implemented together with the NFS server itself. A user can only activate roles to which she has been assigned in the User/Role database. Information about active roles is kept in the role state module. As a rule, a user must independently establish an active role before she can access files through the RBAC NFS server. The exception to this rule is when access to some directory or file has been explicitly granted to a user, for instance to a home directory.

2. After having activated a set of roles, a user application can access a file on the remotely mounted file system. When this happens, the client machine sends an NFS service request to the server.

3. When the server receives a request, it uses the UID of the calling client process as a key to acquire information about what roles the user has active.

4. Having retrieved the currently active roles for the user making a request, the NFS server makes an access control decision for the request using the information in the Role/Permission database. This database assigns permissions to roles authorizing them to access files, directories or directory trees.

5. If the requested access is permitted, the corresponding operation is carried out on the target file system.

6. In our RBAC NFS server design, the owner and permission attributes stored for a file on the Target file system are not used. Instead, in a filtering step, those NFS requests that query permission attributes are intercepted and attributed values based on the information in the Role/Permissions Database are substituted in the reply. The result is then passed back to the client.

Our design implies a change in the conceptual model describing the remote file system. User identity (UID) and group identity (GID) are no longer central concepts, except for conveying information that can be used to tie the UID to a role and for providing access to files that are indeed personal in nature.

However, an important design goal is to achieve a solution that requires no, or minor, changes in client systems and applications. In order for the design to be useful, it must be possible to run most existing applications without modifications.

Since client programs should run unmodified, it is obvious that whatever access rules and access modes we define using the Roles/Permissions Database, we must ultimately map these permissions into file attributes used by the client.

Unix permissions and access modes

In the basic Unix file system model, each file or directory has two important attributes, owner and group. Access rights can be specified to apply for the owner, users belonging to the same group as the group attribute of the file, and for all users not in any of the other two categories. These categories are commonly referred to as ``user'', ```group'', and ``others'' respectively. There are three access modes, read, write, and execute, abbreviated r, w, and x respectively. When listing access attributes, these letters are used if the corresponding access has been assigned, if not, a hyphen, ' -', is used instead. In verbose directory listings, an initial character position gives information on the type of file, followed by three groups of access specifications, for owner, group and others respectively. For instance, ' -rwxr-x---' indicates a directory file to which the user (owner) has read, write, and execute permissions, members of the group the file belongs to have read and execute permissions, and where other users have no rights at all.

Although there are only three kinds of permissions, we can identify ten basic kinds of access modes, create/delete file, create/remove directory, read/write file, execute file, search directory and create hard/symbolic link.

Table 5.2 shows the necessary permissions in order to access a file or directory in different ways. In addition to the permissions shown in the table, it is necessary to have at least execute permission to all directories in the path leading to the accessed file.

  
Table 5.2: Correspondence between access modes and necessary UNIX permissions

The kernel of the client machine enforces access control using the permissions assigned to a file. This is also the case when the file system is mounted over NFS, it is still the client machine that is the access control enforcer, using the permission attributes reported by the NFS server.

Permissions and access modes for our design

The granularity of Unix permissions and access modes is limited.

From table 5.2 it can be seen that there are some access modes that only can be granted together with others. For instance, it is not possible to allow file creation without at the same time allowing creation of directories.

An access mode that often is desirable is append file. However, this mode is not present in the basic Unix model. There is also no way to express that a permission should apply to an entire directory tree.

In the design of the RBAC NFS server, we have tried to address these shortcomings by introducing a different set of permissions. In our design, the basic permissions read, write, and execute, remain the same. However, we make it possible to distinguish between access to files and access to directories. We also introduce an append file permission and allow permissions to apply generally to a directory subtree.

An important file access mode is the operation of changing the file permissions. This is important in a Unix system as it is the characteristic mark of a Discretionary Access Control (DAC) system. In a DAC system, the owner of a file or directory may change the permissions for that object

[DOD85].

However, RBAC is not inherently discretionary in nature. In our system, we use a permission database that assigns file access permissions to roles in an independent manner. Access to modify this database is not given out by default. Applied to our design, this could lead to difficulties. For instance, it would not be possible for a user to write a usable shell script if she could not set the executable permission for the file. To address this problem, we include a special permission that allows this specific operation.

Given these considerations, we decided to implement explicitly permissions for eleven different access modes. These permissions are summarized in table 5.3. For each permission, the table lists a name and a mnemonic that is used when specifying permissions.

  
Table 5.3: Permissions in the RBAC NFS server

Special cases

  Some special issues were considered when designing the RBAC NFS server. None, however, constitutes any serious problem and we therefore discuss them here only briefly. The special cases we identified

were:

Symbolic links.

No special steps need be taken in order to properly handle symbolic links. The permission attributes of a symbolic link are never used. Instead access control is performed when the target of the link is referenced. By convention, the permissions for a symbolic link are listed as `` lrwxrwxrwx''. We, too, adhere to this convention when returning attributes for symbolic links.

Hard links.

Hard links are in fact an alias mechanism that allows a file to have more than one name. This can often lead to confusion. For this reason we do not allow hard links to be created, although existing links in the server file system work correctly, as hard links by definition are indistinguishable from the file itself. We do not believe that this is a significant limitation as symbolic links can be used instead. Also, in our experience, hard links are seldom used in practice.

Should the need arise, our server can be extended to handle hard links as well.

Device files.

Device files are always created directly on the server file system using the mknod command, never using NFS. Indeed, there is no NFS mechanism for creating special files. The handling of access to device files is no different from that of access to other files.

Set UID/GID attribute.

Unix file systems offer a special set user/group id upon execution attribute for executable files. This is an important tool for security administration. As our server does not take into account owner or group ID of a file, the concept of set uid/gid becomes undefined. Therefore, at present, we do not support this attribute. This amounts to assuming that all NFS file systems are mounted using the nosuid option.

Presenting file information

As user and group access attributes are not used, a natural approach is to only use the ``others'' group of file access attributes to convey access control information from the server to the client. This is also the default behavior in our system. As mentioned, one exception to this rule is made for symbolic links, by convention these always have the permission set to `` lrwxrwxrwx''. In order for the others attributes to apply, it is necessary that none of the user or group attributes apply. We achieve this by presenting all files and directories as belonging to user nobody, group nobody (having UID/GID 65534).

However, upon closer examination, it turns out that toggling of the execute bit cannot be implemented using this presentation layout. As Unix only allows the owner of file to change the file attributes, a request to do so for a file to which the user is not the owner does not succeed. Obviously, this would be the case if the owner is set to nobody. The request would be blocked by the kernel of the client machine and not even forwarded to the NFS server. To amend this situation, we set the owner of a file to be the current user if the effective permissions to the file include the execute bit toggle permission (XT). In this case we must also use the user position when specifying access attributes. This solution also has the positive side effect of making a visible distinction between files to which XT permission is granted and files to which it is not. Figure 5.3 shows a typical directory listing. In the listing, read access is granted to the files FILES, README and RELNOTES through role membership. INSTALL and linux are links. Effective access rights for these entries depend on what rights are granted to the target of the links. test.txt is a file to which the user is granted read and write access through role membership. Access rights to the directory mail are through explicit assignment. Finally, the entry for fixit is an example of a file for which the user jsmith can toggle the execute permission.

  
Figure 5.3: Typical directory list appearance

A syntax for specifying RBAC permissions

Permissions are assigned to roles in order to express an access policy for some system resource. In the case of the RBAC NFS server, the system resources in question are directories, directory trees, and files.

For simplicity, the current implementation uses a text file for specifying permissions to access files and directories assigned to roles. Some of the details in this section are specific to the representation we currently use.

  
Figure 5.4: Syntax for role/permissions database

The syntax for writing lines in the permission specification file is shown in figure 5.4. In the syntax, path can either denote a directory or a file. Permissions specified for a directory are assumed to propagate recursively down the directory tree rooted in that directory. When determining which permissions apply to a given directory or file, the entry with the path constituting the longest prefix of the accessed file is always used. This makes it possible to override permissions at points further down a directory hierarchy.

The special syntax `` string ' /*' '' is used to specify a permission policy to be applied to all sub-trees of the directory specified by string. However, the policy does not apply to the directory itself.

Another special syntax is the pseudo-role *everyone* that can be used to introduce a policy that always applies, regardless of which roles the user may have active.

Permissions are expressed using a sequence of colon-separated mnemonics, for instance FR:FC:FW. There is also a shorthand notation for this where FR:FC:FW is written F=RCW.

The algorithm for establishing the effective permissions for a given target-path is to start out with an empty set of effective permissions, P. We then look in the database for the entries having the longest prefix of target-path in their path component. For each such entry we check to see if it has a permission specification for any of the active roles, and for the pseudo role *everyone*. Any permissions thus found are added to the set P.

Figure 5.5 shows an example permissions database. This database describes what access various roles have to different parts of the server file system. In the example, the role sysadm is given complete permissions to the entire file system. By assigning the directory list (DL) privilege to '/' for the pseudo role *everyone*, all users are allowed to browse the contents of the file system. However, when determining the access to a path for a given role, the rule having the longest matching prefix is used. This means that it is possible to block access for *everyone* to the directories /sbin and /usr/sbin by stating alternative rules for these directories, that apply to *everyone* but convey no permissions. The line for /usr/apps/dbms/audit.log demonstrates that access can be specified, and differentiated, for specific files. The next line, for /usr/apps/dbms, gives file read and file execute rights for the directory to the roles manager and clerk. The last line demonstrates how it is still possible to assign a permission directly to an individual user. As in the example, this option is typically used to give users access to a home directory.

  
Figure 5.5: Sample RBAC permission database