RSBAC - Installation and Administration

# Rule Set Based Access Control - Installation and Administration

## Installation and Administration

RSBAC sources come in two parts, kernel patches in the rsbac-patch-*.gz files and administration tools in the rsbac-admin-*.tar.gz files, that have to be installed seperately. All sources can be downloaded via Internet from the RSBAC Homepage at http://www.compuniverse.com/rsbac.

## The Kernel

### Installation

For patching you must have the kernel source tree in the version given installed. You can get it in an archive called linux-2.2.xxx.tar.gz. The archive can be extracted in the directory /usr/src using the command `tar xvzf linux-2.2.xxx.tar.gz`. This will create a subdirectory linux that should be renamed to linux-2.2.xxx-rsbac just to avoid errors later. If a file or directory called linux exists, those must be removed or renamed first. You will need at least 70 MB for the 2.2.2 kernel sources (as an example), including RSBAC patch and object files.

#### a) Applying the Patch (old distribution as big patch)

After that rsbac-patch-*.gz can be decompressed by `gzip -d rsbac-patch-*.gz`. You should move the file rsbac-patch-* into /usr/src as well. Make a backup, if you are using an existing source tree - the patch might not be reversible later. Then you can apply the patch in the kernel main directory /usr/src/linux-2.2.xxx-rsbac by typing
`patch -p1 </usr/src/rsbac-patch-* &>/usr/src/err`
When the patch has finished, you find a protocol in /usr/src/err. If there are any rejects (look for failed in the protocol), you should delete the entire source tree and retry. If it still does not work, please give me or the RSBAC list a note - this is an error that should never happen!

If your kernel source has been changed before, rejects are more likely to happen. The protocol and the files *.rej can help you applying the rest of it by hand. Read Documentation/rsbac/README-patching first! Sure you made a backup before trying, didn't you?

#### b) Installing from tarball

You can simply untar the tar archive rsbac-x.y.z.tar.gz in your main kernel directory. None of the existing files should be changed by this, but some new files are added. RSBAC documentation is placed in Documentation/rsbac/.

To connect the kernel with these files, it has to be patched. The patches reside in the rsbac/ directory, one for each supported kernel version. Apply the patch by calling
gzip -dc rsbac/patch-x.y.z.gz | patch -p1 &>perr
in the main kernel dir. You will find a patch log in perr, there should be no rejects in it. If you patched against another kernel version than stated in the patch, refer to Documentation/rsbac/README-patching.

If your kernel is already patched from another RSBAC version, it is usually enough to untar the tarball and recompile, because the patch is as generic as possible and hardly ever changes. If it does change, you find a clear notice here and in Documentation/rsbac/INSTALL.

### Kernel Configuration and Compilation

Attention: Between RSBAC versions the binary attribute representation on disk can change, though not by recompiling the same version with different settings. You should use the admin tools to make backups before booting an updated kernel! See How to Backup. However, from patch version 1.0.6 there is an auto update of these lists, but there is no way back afterwards apart from backup/restore. Attention: RC model role definitions cannot be auto-updated between 1.0.8a and 1.0.9.

The kernel configuration is done as usual, e.g. by calling `make menuconfig` in the source main directory. In the main menu another submenu called Rule Set Based Access Control appears, in which you find too many choices to present them here. Please see the configuration help for detailed descriptions.

After configuration the kernel is compiled as usual, e.g. using `make bzImage`, and installed with lilo. Before reboot you must install the administration tools, specially the useraci file in it should go into /rsbac (see below), otherwise your system will not come up!

Additionally you should now create two user accounts, one security officer / RC role admin / ACL Supervisor with user ID 400 and, if you intend to use the privacy module, a data protection officer with user ID 401. These can be changed later. You will need them for administration - root will no longer be enough.

If you turned on Role Protection, you will need another, normal user account and the su tool to be able to login as security officer or data protection officer. If both AUTH model and Role Protection are turned on, you are unlikely to be able to access your system at all. In most cases it is better to use AUTH instead of Role Protection.

### Possible Problems

If you get a message rsbac_init(): User ACI could not be read when booting and the system does not come up, the useraci file is not suitable for your system. This usually happens on non-i386 systems. In that case you must reboot an original kernel and create a RSBAC maintenance kernel (use the config option). This should be installed with lilo additional to the first kernel to give you a choice later.

With this kernel active you can use the administration tools to set the roles yourself. If you want, use the user_aci.sh shell script provided with the administration tools. If net support has been compiled in, you might have to set other roles to get some daemons working, e.g. system_admin for bin. After the next reboot of the first kernel the user settings should be working.

If you upgraded your kernel and the data structure for a list type has changed, a warning message will be printed. The data will either be converted from the previous version and booting will continue as usual, or the data will not be read and the device or list will be set to no_write status. No_write can only be turned off via proc interface (see Documentation/rsbac/README-proc). The best way is to backup all attributes before first reboot.

If you chose additional models in the new version, you might have to adjust model related attributes with a maintenance kernel, e.g. user attribute rc_def_role for users 0 and 400. See user_aci.sh in admin tools or models.htm for necessary values.

If the AUTH module is turned on, you might not be able to login, because the login program has insufficient rights to change the process owner (setuid). You can reboot with kernel parameter rsbac_auth_enable_login to get full setuid permissions for /bin/login. As soon as proper authentification is installed and configured, you can turn this back off.

### Kernel Parameters

Lilo

(what's it called on alpha?) allows giving parameters to the kernel at boottime. Most of these give a default debug behaviour, which can be changed later via syscalls or proc interface. The RSBAC system accepts the following other, not data structures, enforcement or decision related debug or help parameters (see README-kernparm for more info):

- rsbac_debug_no_write: Turn writing to disk off for this single boot time. For testing.
- rsbac_debug_write: Debug messages from all attribute writing procedures.
- rsbac_debug_auto: Debug messages from auto-write / rsbacd. Recommended to get an overview of save-to-disk activities.
- rsbac_auth_enable_login: Grant /bin/login full AUTH change owner permission. See above.

## Administration Tools

### Installation

The administration tools in the rsbac-admin-*.tar.gz file can be extracted into any directory, e.g. /root/rsbac, by typing `tar xvzf rsbac-admin-*.tar.gz`. After changing the paths for kernel source main directory, installation and man pages in the file Makefile, a simple `make` creates the tools and `make install` installs them. `make allclean` cleans up your directory afterwards. `make install` also creates the file /rsbac/useraci, if necessary, that you need for booting and administration.

To be able to do this, you must not have an RSBAC kernel active, not even a maintenance kernel. If you upgraded your RSBAC kernel, make an attribute backup under the old maintenance kernel. If you upgraded from an older version than the previous one and get version errors (not upconverts) on reboot, remove the problematic files in /rsbac on all devices with a non-RSBAC kernel before rebooting a maintenance kernel and restoring the attributes. Sure you can always restore the attribute values by hand.

If you intend to use the menu based tools on non-80x25 displays, you should include exports of LINES and COLUMNS in your bash startup file, e.g. /etc/profile, to make use of your bigger screen.

### General Administration

General administration is done via command line tools or via dialog menues on top of these. No RSBAC internal files can be directly accessed. Many runtime settings can now be checked and set via proc interface in proc/rsbac-info, if enabled in kernel configuration, see README-proc in Documentation/rsbac. All command line tools use new system calls provided by the RSBAC package, and all permission checks are done within the kernel. Still, these tools do some sanity checking.

Each tool prints a short help if called with insufficient parameters. The following tools are currently provided:

- attr_get_fd: Read attribute values of FILE, DIR and DEV objects from General Data Structures. Parameters are target type (FILE, DIR or DEV), attribute name and names of files or directories, whose attributes are to be read. Return values are numeric.
- attr_get_file_dir: Newer version from v1.0.1, optimized for scripting
- attr_back_fd: (Recursive) attribute backup for FILE/DIR
- attr_back_dev: (Recursive) attribute backup for DEV
- attr_set_fd: Set attributes accordingly. Recursive setting possible. Parameters are target type (FILE, DIR, DEV or FD(=auto)), attribute name, numeric value and names of files or directories whose attributes are to be read.
- attr_set_file_dir: Newer version from v1.0.1, optimized for scripting
- attr_rm_fd: Reset all attributes of the target given.
- attr_get_up: Read attribute values of USER and PROCESS objects from General Data Structures. Parameters are target type (USER or PROCESS), attribute name and numbers of objects whose attributes are to be read. Return values are numeric.
- attr_get_user: Newer version for USER from v1.0.1, optimized for scripting
- attr_back_user: (Recursive) attribute backup for USER
- attr_get_process: Newer version for PROCESS from v1.0.1, optimized for scripting
- attr_set_up: Set attributes accordingly. Parameters are target type (USER or PROCESS), attribute name, numeric value and numbers of objects whose attributes are to be read.
- attr_set_user: Newer version for USER from v1.0.1, optimized for scripting
- attr_set_process: Newer version for PROCESS from v1.0.1, optimized for scripting
- attr_rm_user: Reset all attributes of the user given.
- attr_get_ipc: New for IPC objects from v1.0.1, optimized for scripting
- attr_set_ipc: New for IPC objects from v1.0.1, optimized for scripting
- rsbac_stats: Return status information on General Data Structures via system log, level KERN_INFO.
- switch_adf_log: Set protocol level for a decision request. Parameters are request name and level (0-2, see Kernel Parameters).
- switch_module: Switch decision modules on or off, if enabled by kernel configuration. Parameters are modules name and 0 or 1. Necessary permissions are module dependent.
- mac_wrap: A wrapper for inetd etc. to reduce maximum security level for a process.
- rsbac_write: request the modified data structures to be written to disk.
- rsbac_check: request the data structures to be checked for consistency. This can also reduce list sizes, because unnecessary entries are deleted.
- rsbac_menu: A dialog menu based administration dispatcher.
- rsbac_fd_menu: A dialog menu based FILE/DIR administration tool.
- rsbac_dev_menu: A dialog menu based DEV administration tool.
- rsbac_user_menu: A dialog menu based USER administration tool.
- rsbac_process_menu: A dialog menu based PROCESS administration tool.
- rsbac_ipc_menu: A dialog menu based IPC administration tool.
- rsbac_dev_menu: A dialog menu based DEV administration tool.
- rsbac_rc_role_menu: A dialog menu based RC role administration tool.
- rsbac_rc_type_menu: A dialog menu based RC type administration tool.

Apart from the Privacy Model, the Role Compatibility model, the AUTH model and the ACL model administration of decision modules is done via setting of attributes. These modules restrict access to their attributes mostly to users in system role Security Officer, which is set for user 400 on installation. If no security officer is defined, a maintenance kernel must be used to assign roles, as described above.

The RC module is administrated via attributes and role and type definitions using the RC admin tools.

The ACL module is administrated via trustee and mask settings for subjects and objects of different types. They are set using the ACL administration tools acl_grant and acl_mask, and they are read with acl_tlist and acl_rights. No general attributes are involved.

Attributes as well as data types for system calls (see types.h, pm_types.h and rc_types.h) containing them are defined and explained in the model descriptions and the syscall man pages. Exact syntax descriptions and numeric codes for attribute values are included in their regarding tool help (call without parameters).

### Administration of the Privacy Module (PM)

As long as this module is active, the general tools (and system calls) for attribute setting no longer work for any privacy relevant attribute. Instead, all administration is done with the rsbac_pm tool, which is merely an interface to the ticket based rsbac_pm system call. This program also accepts names for values, e.g. security_officer for its function set_role. Unfortunately there is no menu based tool so far - still seeking for volunteers...

As assignment of PM roles is itself based on tickets to be issued by a data protection officer and used by a security officer, two different users must have these PM roles assigned via pm_role attribute. This should be automatically done on installation for users 400 (security officer, as for system role) and 401 (data protection officer). If not, boot a maintenance kernel and call
`attr_set_up USER pm_role system_administrator 0`
`attr_set_up USER pm_role security_officer 400`
`attr_set_up USER pm_role data_protection_officer 401`

To define and assign TP values, a TP manager must be defined and assigned his role as well.

### Administration of the Role Compatibility Module (RC)

RC administration can be done at the command line with rc_get_item, rc_set_item and rc_copy_role. The recommended way however is to use the dialog menu based tools rsbac_rc_role_menu and rsbac_rc_type_menu, which provide a comfortable front-end to the commands.

Before starting administration, be sure you understood the model description in models.htm. The use of the tools should then be straight forward.

If the necessary role definitions have not been set for users root (0) and 400, boot a maintenance kernel and call e.g.
`attr_set_up USER rc_def_role 2 0`
`attr_set_up USER rc_def_role 1 400`
This example uses the pre-defined roles System Admin (2) and Role Admin (1).

### Administration of the Access Control Lists Module (ACL)

For ACL administration the command line tools acl_rights, acl_grant, acl_mask and acl_tlist are provided. Everybody familiar with Netware 3.xx (tm) administration should find no difficulty in using them after a brief look into the model description. All others are strongly encouraged to read the model description before changing anything.

## Other Programs

The administration package also includes some other programs, which are described here. Of course those are restricted by access control, too.

- rsbac_pm: Complete administration of the PM module, see above.
- rsbac_stats_pm: Return status information on PM data in Data Structures via system log, level KERN_INFO.
- pm_create: Create files of given object class using rsbac_pm_create system call. Parameters are object class, discretionary mode (e.g. 644) and names of files.
- pm_ct_exec: Execute given program with given current task. Provided for non-rsbac-aware programs that cannot change current task themselves. Parameters are current task, program name and its parameters.
- rc_copy_role: to copy one RC role to another, this is the only official way to add a role.
- rc_get_item: Get an RC role or type entry item.
- rc_set_item: Set an RC role or type entry item.
- rc_role_wrap: Start a program with another RC role.
- rc_get_eff_rights: Get your effective rights on a File/Dir/Dev target.
- auth_set_cap: Add, remove and list process change owner capability sets for processes and files.
- auth_back_cap: Backup file capability sets, similar to attr_back_fd.
- acl_rights: Show a subject's effective rights to an object.
- acl_grant: Change a subject's rights to an object.
- acl_mask: View or set an object's mask for right inheritance.
- acl_tlist: Show a list of subjects with direct rights to an object (trustee list).

## How to backup and restore

Backup has to be done in two steps: Backup of attributes and backup of files and dirs. To backup you first have to switch off all active modules - if you configured the kernel not to switch, you must reboot with a maintenance kernel.

After that you can use attr_back_fd, attr_back_dev and attr_back_user to backup all non-default attributes into restore script files.

If AUTH is enabled, you can use auth_back_cap to backup the file capabilities.

For the ACL model use acl_tlist and acl_mask with parameter -b to produce restore scripts.

Then you can use normal tar etc. commands to backup the files. If you are using the PM module, you should also copy /rsbac/pm_* under a non-RSBAC kernel, since there is currently no other backup method.

To restore, first untar under maintenance kernel, then run restore scripts. This also works with different RSBAC versions and is currently the only way to keep attributes, if the attribute binary structure has changed more than once between your previous and the new version (auto upgrade only knows the previous data structures). If you are using the PM module, you must install the old pm_* files into /rsbac under a non-RSBAC kernel. ACL settings are restored by running the restore scripts.

## RSBAC Demonstration Examples

For demonstration purposes a

simple Privacy Model (PM) application example has been developed together with Simone Fischer-Hübner. Although several modules are used, our focus clearly lay on the privacy model, being the most complex and powerful at the time. Other modules are used for special purposes.

Also some case examples are currently developed for the enhanced RC model, which will be presented later.

Back to RSBAC homepage

- Questions, tips, etc.

27-Sep-99, -ao