RSBAC sources come in two parts, kernel extension and patches in the rsbac-*.tar.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.rsbac.de/rsbac.
For installation you must have the kernel source tree in a supported version 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 e.g. 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 80 MB for the 2.2.12 kernel sources (as an example), including RSBAC patch and object files.
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?
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 (what is not
recommended), 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.
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 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.
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.
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):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.
If compilation with egcs fails with a register error, try removing optimization parameter -O2 in the Makefile (see comments). This is an egcs optimization bug.
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 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:
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. The ACL menues are recommended.
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).
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.
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).
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.
Also, there are two menu tools, rsbac_acl_menu and rsbac_acl_group_menu, which can make life much easier.
The administration package also includes some other programs, which are described here. Of course those are restricted by access control, too.
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, acl_mask and acl_group with parameter -b to produce restore scripts. See tool help screens for parameters.
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 and there is no auto upgrade. 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.
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
-05-Jan-00, -ao