If you employ RSBAC you have to try to limit yourself to using the modules/models your really need - and, most important: that you really understand. The 'common' needs are covered quite well by using a combination of the AUTH, RC en FF models. I will describe some of the most used models and modules below.
All other models (ACL, MAC, FC, SIM, PM, MS, CAP en REG) are specifically used for uncommon needs. I will not describe them in this introduction but you can find full descriptions of these models in the section RSBAC Models in The RSBAC reference manual.
Some of these lesser used models serve as practical demonstrations for some security theory. Some of them overlap in functionality. Others are complex and hard to administer. The FC model on the other hand is regarded upon as hard to employ because it allows only low granularity. The RSBAC PM model allows a correct implementation of the rules of the strict European privacy regulations and laws in automated systems. To the best of my knowledge it is the only implementation of that functionality existing today.
The wealth of available models can easily confuse the novice. In itself the number of ready-to-use modules makes a strong point for the software: you can freely choose from all of them. Models you do not understand (let alone use) can be left out during installation. They will not use any of your precious resources.
Another important module is the REG module. It is not a conventional module but offers an interface annex framework to create your own security modules. Modules built using the REG module can be loaded as if they were regular kernel modules. The RSBAC source code contains a number of examples how to use the REG module. If you have any special security needs that can not be satisfied by one or more of the existing modules you can roll your own. Very powerful.
The AUTH module is a mandatory part of RSBAC. Its provides functionality needed by all other modules. AUTH allows subjects to change their identity - in other words to AUTHenticate themselves. The Linux implementation of the AUTH module handles requests from a process to change its UID. Whether or not a call to change UID should be accepted is decided by inspecting the configuration data stored in the ACI.
Of course the actual system call can only be executed by a running process but administration of these rights is done by allowing programs to execute AUTH rights. The configuration data is normally kept in non-volatile memory (actually a part of your hard disk), the ACI. If such a program is loaded within a process the rights of that program are inherited by the process itself. So when that process requests a change of UID the AUTH module will allow it. By default no program/process has rights to change its UID[1].
AUTH permissions can be issued on two levels: either a process/program is allowed to assume any UID it wants to (auth_may_setuid) or you have to provide the module with a list of UID's a program may assume (its 'capabilities'). The functionality both methods offer is basically the same: setting auth_may_setuid can be thought of as setting all possible capabilities for a UID.
You can configure the AUTH module using the command line utility 'auth_set_cap'. By default this program will only accept calls from the security officer (defaults to UID 400).
The File Flags model allows you to set additional attributes for files, fifo's and directories. These attributes are enforced upon all subjects (processes) on the system. As always the ACI is used to store the additional attributes. If you set additional attributs for an object the following nine bits of data will be stored in the ACI (the value within brackets indicates which bit is used): read_only (1), execute_only (2), search_only (4), write_only (8), secure_delete (16), no_execute (32), no_delete_or_rename (64), add_inherited (128) and append_only (256). What they do can mostly be determined from their names, but I will elaborate on some of these:
if you set the secure_delete flag for an object this signifies that the actual data in a file will be overwritten (using NULL-characters) if you delete the file. This makes it much more difficult to reconstruct what has been in the file. RSBAC is mostly filesystem independent and should thus work with any local filesystem. It has been tested (and works with) ext2, ext3, reiserfs (without inode number checking and secure_delete), xfs, minix and (v)fat[2].
by setting the add_inherited flag you specify that the object will inherit the attributes of its parent directory. Be careful when setting this attribute: it may result in inaccessible files, for example if a directory has the read_only attribute set and you specify write_only en add_inherited for a file in that directory.
Most rights are inherited - in other words: by setting a flag on a directory the flag also is set for all objects (files/directories/fifo's) within that directory. This does not hold true for the add_inherited and secure_delete bits.
To set a fileflag you can use the command line utility attr_set_fd, for example:
$ attr_set_fd FD ff_flags 1 /a/b/c
Alas you need to calculate the bitmask yourself if you use
the attr_set_fd command. For example to
set both 'secure_delete' (16) and
'no_execute' (32) you would have to use 48
as fourth argument. Alternately you may set the FF
flags using the command attr_set_file_dir, which
allows the use of add/remove flags. To query the current file attributes
you can use the utilitiy attr_get_fd and to reset/remove
attributes you need to use attr_rm_fd. Again:
by default only the security officer can alter the file flag
permissions.
The Role Compatibility model closely resembles the way people think. People will typically describe security issues in terms like for example: 'an operator should only be allowed to read logfiles'. The operator represents a role in a proces. The RC model also uses the 'roles' concept. A role can be seen as a label that belongs to a set of tasks a user may perform, like 'webmaster' or 'operator'. Such a role comes with a number of permissions to gain access to (certain) (classes of) objects.
The objects are categorised in 'types', which in turn can be given meaningful names like 'logfiles' or 'webdocuments'. A 'role' is granted access to certain 'types', for example: the 'operator' is allowed to access objects of type 'logfile', a 'webmaster' is allowed to access objects of type 'webpage'. What type of access a certain 'role' is granted can be specified too, so let's say that an 'operator' is allowed to access 'logfiles' - but he is only allowed to read them. Within the RC model we distinguish between objects of class FD (Files/Directories), objects of class IPC, of class DEV, SCD and PROCESS.
By using the RC model a subject is only allowed acces to certain forms of access to objects by assuming a 'role'. To do so, the subject needs authorisation. If authorised, the subject gains access to any object that is 'compatible' with his role. Any subject (process) is granted an initial role - and that role is inherited by any subject that is generated by it. On a Linux box a subject is a process and its rights are inherited by its children. So, when for example a user (Mary Model) logges in her login process will automatically assume the default role assigned to her, let's assume it is named 'rolemodel'. Now, all processes spawned by Mary's login are able to excersize any rights 'compatible' with the role 'rolemodel'.
The RC model allowes a subject to change its role. To do so, the subject needs to issue a special system call or it needs to load a program that has a 'forced role' set. More about 'forced roles' later. You can only change roles if the roles are 'compatible' - changing roles is only allowed if the security officer allowed it. Furthermore changing from role A into role B does not imply that you are allowed to change back from role B into role A. In other words: role B can be incompatible with role A while role A is compatible with role B.
Be careful: there is no mandatory relation between the UID of a subject (process) and its RC role. It might be that a process has the role 'operator' set and - assuming that the role 'operator' allows it - that process is allowed to change its UID but it still will be in its initial 'operator' role. To change to the default role for a UID you need to have your software perform an additional system call.
It is possible to set an attribute for a program to indicate it has a 'forced role': if any process loads that program the process will obtain the rights for that role. This somewhat resembles setting a set-uid bit on a program. It allows you to create programs that have access to certain objects by allowing a certain role to access the objects and consequently force that role upon the program.
Executables that do not have a role forced upon them by default inherit the role of the process that loads the program. Alternately you can set a flag to indicate that the program should inherit the default role of its UID. The program should have the setuid bit set and you should configure the AUTH module to allow that UID change.
These concepts are best illustrated using an example. We assume we want to create an anonymous ftp server. Such a server is typically run from within a chrooted jail which - even on a non RSBAC system - prevents us from many security breaches. We can increase our servers security even more by using the RC model.
To do so we create a role 'ftpserver'. We also add a new objecttype: the FD objecttype 'publicfile'. The program that implements our ftp server is given the default role 'ftpserver', which implies that all processes that load this program and al their children will inherit the privileges and restrictions for that role. Next we configure the toplevel directory for our ftp server to be of type 'publicfile' and by doing so imply that all subdirectories and files will also be of that type.
Then we configure the role 'ftpserver' and restrict its rights to reading and searching objecttypes 'publicfile'. Our ftp server also needs rights to access our network, so we need to define an additional object type: an IPC object type 'ftpnet'. The role 'ftpserver' will be granted the CREATE and DELETE rights on objects of type 'ftpnet' and for the role 'ftpserver' the default IPC type is set to 'ftpnet'.
By configuring it like this, it is impossible for the ftpserver to execute or delete any file in its subdirectories. Even when the ftpserver runs with superuser privileges and has bugs the size of Paris no harm can be done by it - the RC model prevents this.
If for whatever reason you want to be able to execute a file from within the ftp server - for example a copy of /bin/ls - you can create another role, let's say 'ftp-executable', which can be a copy of the role 'ftpserver', but with additional rights to enable it to execute files. By granting the copy of /bin/ls a forced role 'ftp-executable' the ftp server process that loads that program will inherit the proper rights to execute the program.
The tools to configure the RC module are rc_copy_role, rc_get_item and rc_set_item. Again, these tools can only be used by the security officer by default. The RSBAC documentation contains an good example too on how to configure a (more) secure webserver.
| [1] | Which can be very frustrating for novice RSBAC users: after they have installed RSBAC and rebooted their new kernel they find out that they are not able to log on into their system anymore - by default the program /bin/login is not allowed to change UID either. However, there is a good workaround available to solve that problem: you can start up a newly installed RSBAC kernel with the rsbac_auth_enable_login option, which will allow /bin/login to change UID so you can log in. Note that this requires physical access to the system. |
| [2] | To be precise: secure truncation should work on all filesystems, but secure delete requires changes in the filesystem code. Since for example xfs is not part of 2.2 or 2.4 kernels, secure delete is not supported for it. In general it is considered dangereous to use secure delete on journalled filesystems. Please consider using encryption instead. |