A step further with RC

Stripping root of its power

So far, although we have done much to protect files from general users, we have done little to reduce the power of the root account. This is because the root account still has the role of System_Admin. Should an attacker compromise a daemon process, or gain root access in some other way, we would, therefore, still be just as vulnerable.

A simple solution to this problem would seem to be to assign the root account the same default role as a general user. This approach suffers from several problems however. If the root account is to start daemon processes then its default role will need to be compatible with the forced role assigned to said processes. If we assign the root account the same default role as general users they too would acquire role compatibility with the roles defined for daemon processes. Another, less serious problem, is that we don't want general users to be able to read some files which the root account will require access to and vice versa.

A better solution would probably be to create a new role for the root account and assign that role the minimum rights required. This approach would avoid all the pitfalls of the more simple solution proposed above and would also allow us to specify RC types that the root account should not have access to.

The General User role makes a good starting point for the new role as it already has some basic, very minimal, permissions assigned to it so lets begin by making a copy of that role called DefRootRole. We can do this by using the rsbac_rc_role_menu application to copy a role as we did earlier when we copied the General_FD RC type. Alternatively we can do it from the command line as shown below.

secoff@lisa ~ $ rc_copy_role 0 4
secoff@lisa ~ $ rc_set_item ROLE 4 name DefRootRole

Now that we have a new role called DefRootRole we can assign that role as the default role for the root account. As we want to make some other changes to the root account as well it is probably easiest to do so using the rsbac_user_menu application.

secoff@lisa ~ $ rsbac_user_menu root

Change the default role to the DefRootRole role which we created earlier so that the root account will start in this role.

At the moment the root account can be modified by anyone with sufficient access rights to modify General User accounts. As the root account is used by the operating system we should probably change the RC type so that only those with authority to modify System User accounts have access.

We should also ensure that the root account does not have the ability to modify other services, especially the AUTH module. To do this set the other roles for the root account to General User.

If you have modified your bash profile as suggested earlier you can verify that this has worked, and that the root account is indeed now assigned the default role of DefRootRole, by logging in as root. You should see the role shown in the prompt as below.

(DefRootRole) lisa ~ #

Powerless root

Of course, now that we have stripped the root account of all its power it is pretty much useless. We can't use it to start daemon processes as it doesn't have access to the init scripts. We can't use it to install software as it doesn't have write access to any files. In fact we can't even execute binaries in the /sbin or /usr/sbin directories!

System binaries

Lets start with the /sbin and /usr/sbin directories. The root account is useless without access to these after all. As we have already covered everything that we need to know to perform this task it would be pointless to go over it again in detail. A brief reminder of the required steps however may prove useful.

Copy the System_FD type to a new type called SysExecutables.
Assign the SysExecutables type to the /sbin and /usr/sbin directories.
Grant EXECUTE and MAP_EXEC rights, in addition to Read Requests, on the SysExecutables FD type for the DefRootRole role.

We made a copy of the System_FD type rather than the General_FD type as the permissions are already set correctly for the General Users role as well as the System Admin and Role Admin roles. Had we used the General_FD type we would have needed to unset the permissions for General Users.

Init scripts

Now that the root account has the ability to execute binaries from the /sbin and /usr/sbin directories we can turn our attention to the next item on our list, the init scripts, which are located in the /etc/init.d directory.

The root account needs to be able to execute the scripts in this directory to start and stop daemon process so we could assign them the SysExecutables type which we created earlier. While this would fulfil the goal of allowing root to execute them it would not be as flexible, or secure, as creating a new RC type to represent this class of object. It also allows us to specify a forced role for the init scripts which restricts their access to other init scripts while still allowing them to execute binaries assigned the SysExecutables type.

As before a detailed description of how to perform these tasks would be pointless as they have been covered in previous sections. An outline of the required process is given below for your convenience.

Copy the SysExecutables type to a new type called InitScripts.
Assign the InitScripts type to the /etc/init.d directory.
Remove the MAP_EXEC permission from the DefRootRole role.

As before we made a copy of an existing RC type, in this case the SysExecutables type, to save ourselves some work. If you prefer you can create a new type from scratch however you will need to remember to assign the correct permissions to all the other roles if you do.