A simple ACL policy

Base protection

Now that we have an idea of what the ACL module can do to help us secure our system lets start to implement some base policy decisions.

We know that we are going to need a sysadmin user account and group so we should create them now. The following commands will perform these tasks using the newly installed RSBAC user administration tools:

You must be logged in as the root user as Linux filesystem permissions are still active.

 

Once the sysadmin user and group has been created we can begin to configure our security policy. Start by opening the RSBAC ACL Administration application.

You should be logged in as the secoff user. Also remember to change to the root directory as we are going to manipulate the global default filesystem ACL.

 

When the RSBAC ACL Administration application starts you will be presented with a menu offering a list of all the object types which can have an ACL set on them. As you can see this is a comprehensive list allowing security to be set on a wide variety of system objects.

For now we are only interested in securing our filesystem so select the first option from the object type menu

and press enter to display the Main Menu for FD objects.

The RSBAC ACL Administration Main Menu is divided into four sections. The first section provides menu options to select an object from a list, select an object by entering its name and an option to return to the object type menu. The second section provides menu options to add, remove and change the TTL of an ACL entry as well as options to choose the display mode, display the current rights of users, groups, roles or types and an option to change the inheritance mask. The next section lists the current ACL entries and allows their permissions to be modified. The fourth and final section provides an option to clear the ACL as well as options to go to other menus in the RSBAC menu structure.

We want to change the permissions currently available to the special group 'Everyone' so select that option from the list

and press enter to display the permissions menu.

The permissions are fairly self explanatory so there is little point describing them here. There are however some special options after the list of permissions which will be of use to us now so a brief explanation is in order. These options set various standard classes of permission. They are also cumulative so if you select more than one they will be applied in sequence.

A good set of default permissions would probably allow everyone to read everything so we can use two of the special options to achieve this. Select the following special options

and press enter. If you want to verify the permissions which have been set by this special option press enter again. You can return to the main menu without making any changes by pressing escape. To quit the application press escape.

That is a good start for the Everyone special group but the root user still has write access to everything. If we are to restrict the power of the root user as much as possible so that a compromised daemon processes cannot run amok we need to reassign the access rights currently enjoyed by root to the sysadmin user.

So far we have created an RSBAC user account and a Linux group for the sysadmin user. It would be nice if we could have a group of system administrators with access to everything. As an ACL entry can't be added for a Linux group we need to create an ACL group. This can be done using the rsbac_acl_group_menu application or more easily from the command line as shown below:

We can then add the sysadmin user to this group using the command below:

Now that the SysAdmin ACL group has been created and the sysadmin user has been added to it we can use the rsbac_acl_menu application again to set the permissions.

Choose the FD menu item and you will be presented with the main RSBAC ACL Administration menu for the default ACL on the root directory. This menu contains an option to add a new ACL entry. Select that menu option and you will be presented with a list of the types of subject available. We are interested in adding an ACL group so select that option

and then select the SysAdmin group as shown below:

You will be shown the list of available permissions as before. As we want the system administrator to be able to perform both read and write access as well as system and security related activities we should chose the following special options.

Make sure that you do not give ACL Special Request permissions to the SysAdmin group or they will be able to override the settings specified by the Security Officer.

 

Now that we have given the system administrator the ability to write to all filesystem objects we can remove the ACL entry for the root user. To do this select the Remove Entry option from the Main Menu and then select the root user from the list. One the root user has been removed you can press escape to return to the main menu and then again to quit the ACL Administration application.

Congratulations! You have just set a default ACL policy for the entire filesystem.

What about executables?

As you may have noticed when we were setting the permissions on the default ACL for the root directory we left execute permissions unset for all types of user. 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?

User executables

We clearly need to refine our ACL policy to allow the execution of binary files stored in the standard locations. This can be done most easily using the rsbac_fd_menu application with the path specified on the command line

and from there navigating to the ACL menu.

Once you are at the ACL Administration Main Menu you can select the Add ACL Entry option to add, or in this case override an ACL. We want to allow everyone to execute binary files located in /bin so you should select ACL group and then the 'Everyone' special group. From the next menu you should add the permissions required to execute binary files and scripts. For your convenience these are given below:

Now that we can execute binary files contained in the /bin directory we should repeat the process for the other directories containing user accessible binaries.

System executables

In the previous section we set execute permissions on binary files in the standard locations for normal users. This is only a third of the story when it comes to executables on Linux. There are also a whole raft of binary files stored under the sbin equivalents of the paths above. These should only have execute permissions for the root user.

To allow root to execute system binary files you should repeat the procedure outlined above but instead of adding the ACL group 'Everyone' you should add the user root.

Init scripts

The init scripts stored in /etc/init.d also need to be readable and executable by root.

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, and thus complete the three stages of configuring Linux executables, we need to set the permissions on /lib to allow mapped execution.

To do this open the rsbac_fd_menu application on the /lib directory and create an ACL entry for the 'Everyone' special group with the following permissions set:

To complete the process you will need to repeat the above procedure for the /usr/lib and /usr/local/lib directories.

Write access

Whilst our ACL policy looks good so far for read-only files there are some files which need to be written to.

Temporary files

Probably The most notable location requiring write access is /tmp which needs to be writable by everyone. We can still provide some additional security however by not allowing files to be executed. This is most easily accomplished by creating an ACL entry on /tmp for the 'Everyone' ACL group and setting the Read Requests and Write Requests options on that ACL entry.

Spool files

That takes care of files which need to be writable by everyone but there are some files which need to be writable only by special users. The first such location to be addressed is the /var/spool directory. This directory requires read/write access permissions for the root user so that daemon processes can create files there. The most notable of these is probably the cron process which writes lock files and the output of each run to a subdirectory of this location.

PID files

root needs write access to /var/run

Init scripts

The init script system also requires root to be able to write to the /var/lib/init.d directory.

System log files

syslog-ng can't be non-root because of /proc/kmsg

give root write access to /var/log for now

give root write access to /dev for now

dnslog needs write access to /var/dnscache/log