The beginnings of an RC policy

Base protection

Lets get our hands dirty with a concrete example we can all appreciate.

Wouldn't it be nice if we could somehow protect all the important files on the system against unauthorised modification, even against an attacker who has gained root privileges? We could rest much more easily. Lets do that now then.

Default FD type

As we saw earlier in the section on the ACL model ACI attributes in RSBAC are inherited by their child objects. As there is currently no RC type assigned to the root directory the default RC type for that directory, and therefore for all files and subdirectories thereof, is set to an unknown value.

As there is already an FD (File / Directory) type called General_FD we can put it to work right away by assigning it as the RC Type FD for the root directory.

When you execute the above command you will be presented with the familiar RSBAC menu system. Find the option shown below

and change it so that it looks like this.

Default permissions

Once we have assigned a type to some objects, in this case all objects, we can think about who should have access to them. For a Linux system to be usable it is expected that certain files and directories will be readable by everyone so that sounds like a good place to start. We now know that we want all general files to be readable by all general users.

We would normally have to create a new role for this purpose however there is a role provided with the default configuration called General User which sounds about perfect for our uses. As the role already exists, and all general users already have it set as their RC Default Role, we can move right on to the compatibility phase.

Select the General User role from the list, as shown below, and press enter to see the main menu for that role.

Locate the Type Comp FD option from the menu and press enter again to see the list of available FD types as shown below.

Select the General FD type from the list and press enter once again to see the available permissions.

As you can see there are a lot of available permissions, and most of them are currently set. At the bottom of the list of permissions there are some convenience options which will be of use to us here.

Highlight the Unset ALL option and press the space bar to put a check next to it. Now move down two lines and check the Set Read Requests option. When you press enter both options will be applied in turn. You can press enter again to make sure. Press escape three times to quit.

Congratulations! You have just set your first RC based policy.

Not to put a spoiler on things but it should be noted that RC configuration is a long way from being completed at this point. Read on to find out how to do trivial things like letting users execute binaries!

 

What about executables?

As you may have noticed when we were setting the permissions on the General User - General FD mapping we left execute permissions unset. This is obviously the right thing to do, we don't want people executing things from just anywhere after all, but how do we run our executables now?

Defining the problem

The easiest way to understand the required components of an RC policy is to go back to basics and think of which activities do we want users in which roles to be able to perform on which types of object.

It is clear from the previous paragraph that we want binary execution to be allowed for general users on all non-secure executable objects.

Creating the RC type

As usual we shall begin in reverse order by creating the RC Type to represent the class of objects we are working with - in this case Executables.

We want to create a new FD (File or Directory) type so select that option from the list, as shown below.

As you can see the types which are already defined are displayed below the menu options.

Select Copy Complete Type from the Main Menu and press enter. A list of available types will be displayed. Select the first entry in the list - General_FD - and press enter to display the destination menu.

Select the unused option which is offered and press enter again. A new entry, with the same name as the type which was copied, will be shown in the list of available types.

Highlight it and press enter to display a dialog allowing a new name to be specified. Enter the new name as Executables and press enter to accept it. The list should now reflect the new name.

Assuming that everything went well quit the application by pressing escape.

Setting the object type

Now that we have created a type for our class of objects it is time to assign that type to some real instances of those objects.

We can begin by using the rsbac_fd_menu application to set the RC Type FD on /bin.

Before we set an RC type on the /bin directory it is worth examining one of the other options on this menu.

In its current state (real) the access control information displayed is that which is currently set on this object. If you highlight that option and press enter it will change to show

The access control information which is now being displayed is that which is effective on this object and its parent objects, all the way to the top of the tree unless the option in question is overridden.

You can see that in effective mode the RC Type FD is being shown as the same as that which we set on the root directory earlier.

If you toggle back to real mode you can see that it returns to showing the current ACI as set on this object.

We want the /bin directory to be assigned the type which we created earlier so highlight it, press enter, and select Executables from the list. Press enter again and you should see the following:

Assuming that all went well you can quit the rsbac_fd_menu application by pressing escape.

Setting the role's permissions

All that remains to be done is to set the permissions that we want to be applied to the General Users role when accessing objects of the type Executables.

As you can see here the role name can be specified on the command line to save selecting it from the menu.

 

Using the menu select the

option and then the

type that we created earlier to see the list of available permissions.

The permissions set at the moment are identical to those set for the General FD type. We saved ourselves some effort by making a copy of the General FD type earlier instead of creating a new one from scratch. To achieve our goal of letting General Users execute binary files we need to set the following flags in addition to those already present:

More to do about executables

In the previous section we took care of executable files in the /bin directory by assigning it the Executables type. There are, however, other executables which we may need to access. These are commonly located in the /usr/bin and /usr/local/bin directories.

We can do this now using the rsbac_fd_menu application. Refer back to the previous chapter if you have forgotten how. As a reminder we are setting the RC Type FD to Executables.

Alternatively the above tasks can be accomplished entirely from the command line as shown below.

Don't forget the libraries

While the policy changes we have made in the previous sections allow users to execute binary files they only allow the execution of self contained binary files.

To allow the execution of applications which use dynamically linked libraries we need to perform some additional work. The tasks which are required are outlined below:

• Create a new RC type called Libraries
• Assign the RC type to the library files
• Set role permissions

Library files only require the MAP_EXEC permission as they are only ever executed when mapped into an existing process.

 

If you have forgotten how to perform the above tasks refer back to the previous sections.

Don't forget that library files are stored in the /var/lib directory as well as /lib and /usr/lib.