Implementation

The implementation was made using a publicly available NFS server as a starting point. The server software is in common use on Linux systems [SBS95]. Our augmented server currently runs on a Pentium PC running Linux 2.0.29 and is accessed over a standard 10 MBit/s Ethernet network.

As can be seen from figure 5.2, two main additions have been made to the original NFS server.

One addition deals

with the assignment of users to roles and the management of role activation and deactivation. The other addition is responsible for implementing the new, role-based, access control semantics as described in section 5.2.

Implementing roles

In order to use the concept of role, there must be a

an administrative tool

to define roles, it must be possible to assign roles to individuals, and there has to be a mechanism whereby roles may be activated. As stated initially, this task would normally be handled by an underlying security infrastructure. However, for the purpose of demonstration, we have implemented a client program that allows a user to communicate with a role state server adjacent to the NFS server. Using the client program, the user can activate and deactivate roles according to the assignments made in the User/Role database. This database is a simple text file that for each role lists which users may activate it.

Introducing RBAC semantics in the NFS server

By definition, any NFS server is built around the functions implementing the services defined in the protocol. We have introduced a two tier enforcement of RBAC in the server. The first tier delegates access control to the client machine by assigning suitable file attributes to referenced files. In many cases this is sufficient in order for the client machine itself to enforce access control. In the second tier, a check is made upon each service request to determine whether performing the request is allowed or not given the set of active roles for the current user. The modifications we have made can be summarized as follows.

Role establishment.

In the original server, the first step taken when a service function is called is to authenticate the file handle, the calling machine, and the calling user. To this sequence we have inserted code that establishes a set of active roles for the duration of the call.

File attribute assignment.

All read accesses to file attributes go through one function. Before returning from this function we have inserted a filter that clears out the access mode bits and substitutes a mode that is derived by combining (using bitwise or) the necessary access modes (see table 5.3) corresponding to each permission granted for the file to each active role. We also preserve the original value of the execute bit.

Access control at service request time.

Here, a categorization into three categories can be made

1. No check. The getattr, lookup, and readlink services fall into this category, together with the unused or obsolete services.

2. Access permitted after check. The majority of NFS functions belong here. We have inserted code that checks if the requested access is permitted considering the set of active roles and the target path for the request. If this test fails, execution of the function is aborted and an access error status code is returned.

3. Access disallowed for all calls. Currently, for reasons set out in section 5.2.3, only the link call is disallowed.