RSBAC - Installation and Administration

| # Rule Set Based Access Control (RSBAC) for Linux - Installation and Administration

## Installation and Administration

RSBAC sources come in three parts:

1. kernel extensions in the rsbac-*.tar.gz files
2. kernel patches to connect them to the kernel in the patch-x.y.z.gz files
3. 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.org.

For beginners, there is also a good RSBAC for Beginners page on linux.ru.net.

## The Kernel

### Installation

#### Quick Install:

To install RSBAC version A.B.C with kernel version X.Y.Z do:

1. Download or copy all files you need into your current directory (or change paths below): Get linux-X.Y.Z.tar.bz2 from your local ftp.kernel.org mirror, rsbac-vA.B.C.tar.bz2, patch-X.Y.Z-vA.B.C.gz from www.rsbac.org/code or www.rsbac.org/pre. Alternatively, you can download a pre-patched kernel from www.rsbac.org/kernels, unpack it and go to step 6.
2. Unpack kernel source tree: tar xvIf linux-X.Y.Z.tar.bz2
3. cd linux
4. Unpack RSBAC tar archive: tar xvIf ../rsbac-vA.B.C.bz2
5. Patch the kernel (and possibly some RSBAC files): gzip -dc ../patch-X.Y.Z-vA.B.C.gz | patch -p1
6. make menuconfig
7. touch Makefile
8. make dep bzImage modules modules_install
9. Install the new kernel arch/<arch-name>/boot/bzImage with your favourite boot loader.

#### Detailed Version:

For installation you must have the kernel source tree in a supported version installed. You can get it in an archive called linux-2.x.y.tar.gz. The archive can be extracted in the directory /usr/src using the command `tar xvzf linux-2.x.y.tar.gz`. This will create a subdirectory linux that should be renamed to e.g. linux-2.x.y-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 130 MB for the 2.2.20 kernel sources and 190 MB for the 2.4.18 kernel sources, including RSBAC and object files.

#### a) (OLD!) Applying the big patch (old distribution as big patch, up to v1.0.8a)

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 (from v1.0.9 on)

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 overwritten, 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. Up to version 1.0.9a, the patches reside in the rsbac/ directory, one for each supported kernel version. From 1.0.9b onwards, the patches must be downloaded separately - there are just too many of them by now. Apply the patch by calling
gzip -dc patch-x.y.z-va.b.c.gz | patch -p1 &>perr
in the main kernel dir, but after unpacking the rsbac tar archive. 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) or got rejects in a distribution specific source tree, refer to Documentation/rsbac/README-patching.

If your kernel is already patched from another RSBAC version, it might be enough to untar the tarball and recompile, because the patch is as generic as possible. However, it does change quite often, but you will find a clear notice here and in Documentation/rsbac/INSTALL.

Patch changes for version:

- 1.0.9b
- 1.1.0
- 1.1.1
- 1.1.2
- 1.2.0

### 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 (except from 1.1.2 to 1.2.0), 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. There is no auto-update from 1.1.2 to 1.2.0, please see Upgrading below.

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.

Specially for beginners, it is recommended to enable the RSBAC soft mode. It will give you a kernel boot switch to turn off access control while keeping the decision logging - a good way of keeping you system running while getting used to RSBAC settings. On a production system, it should certainly be kept off.

For version file dependency reasons you have to call 'touch Makefile' next, to get the new version string with '-rsbac' used. If you do not like the -rsbac extension, just disable its setting in the Makefile. However, modules for kernels with and without RSBAC should not be mixed in the same modules dir.

After configuration the kernel is compiled as usual, e.g. using `make bzImage`, and installed with lilo.

With RSBAC versions before 1.0.9b, you must install the administration tools before reboot, specially the useraci file in it should go into /rsbac (see below), otherwise your system will not come up! From 1.0.9b there is an automatic standard setup, if user attributes cannot be read, and the standard useraci is no longer provided.

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 (PM), 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 really have to change these default numbers, please only change the macros RSBAC_SECOFF_UID and RSBAC_DATAPROT_UID in include/rsbac/types.h. From version 1.2.0, you can turn on the 'Show more options' switch in kernel config and change the numbers there.

(Obsolete from 1.2.0) 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. For this reason, Role Protection is marked as 'discouraged' from v1.1.1 and has been removed in 1.2.0.

### The First Boot

Please note that the following will only appear in the system log, but will not be enforced, if soft mode is active. You can enable soft mode (if supported through kernel configuration, s.a.) with the kernel boot parameter `rsbac_softmode`, or enable/disable it at runtime as user 400 through the /proc/rsbac-info/debug interface (see Documentation/rsbac/README-proc). The current soft mode status is shown in /proc/rsbac-info/{stats|debug}.

When booting your new RSBAC kernel with AUTH model for the first time, please do not forget to add the kernel parameter rsbac_auth_enable_login, e.g. at lilo prompt type (assuming your image name is rsbac)
`rsbac rsbac_auth_enable_login
` If you forget this, you will not be able to login and have to reboot, e.g. via CTRL-ALT-DEL.

During boot you will see a lot of RSBAC messages from rsbac_init() etc. There may even be some error messages like 'xyz could not be read, error RSBAC_ENOTFOUND'. These (now) harmless errors indicate that there are simply no Access Control Information (ACI) files to be read, because you never set any attributes. They are necessary in case an attribute list got lost because of some system failure, to tell the admin on reboot. Some lists are automatically created to get your system working, but others are not.

If you included AUTH in your list of selected models, some daemons will try to setuid and fail. This shows that AUTH is working fine: they are not allowed to setuid without permission. One of your first administration task will be setting the required AUTH capabilities for daemons, e.g. with the rsbac_fd_menu. Just login as user 400 (s.a.), call
`rsbac_fd_menu <name-of-daemon-executable>`
and you can do this via menu, item AUTH capabilities. The necessary user IDs are in the system log, look for CHANGE_OWNER requests that are NOT_GRANTED and take the attribute value.

### Possible Problems / Maintenance Mode

If, for what reason ever, your system becomes unaccessible, or if you want to make backups without access restrictions, you can generate an RSBAC maintenance kernel. This kernel has all RSBAC access control switched off, so all users can change settings without restriction.

From v1.1.1 onwards, there is also the 'Soft Mode' option that lets you turn off access control at runtime. Please use both options with care, because they can lead to huge security holes!

For Maintenance Mode, just turn it on in the RSBAC kernel configuration. This kernel should be installed with lilo etc. additional to the first kernel to give you a choice later. It is advisable to remove network support in such a kernel to protect against security holes during maintenance.

(Obsolete from 1.0.9b) In RSBAC versions up to 1.0.9a, if you get a message rsbac_init(): User ACI could not be read when booting and the system does not come up, the standard useraci file is not suitable for your system. This usually happens on non-i386 systems. In that case you must reboot with an RSBAC maintenance kernel (see above). Then you can setup roles etc. as any user, e.g. using the script user_aci.sh in the admin tools directory. If it still does not work, please ask for help on the RSBAC mailing list.

(Obsolete outside 1.1.0) In RSBAC version 1.1.0, there is a bug in the ACL model default settings, preventing execution of some files. Please make sure that you applied the bugfix for this.

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.

Also with AUTH enabled, some daemons might not be working properly, because they get their setuid requests denied. In this case, the security officer (secoff, id 400) should add an AUTH capability to the daemon binary for the target user. You will easily identify these cases from the system log: the daemon's CHANGE_OWNER request for its process id, attribute owner, attr_val xyz will return NOT_GRANTED. Pick the uid xyz and set the capability with rsbac_fd_menu filename.

### Upgrading RSBAC

#### From 1.1.2 to 1.2.0

Due to major changes in the list management code, e.g. moving to generic lists, there is no automatic updating of your old data structures possible. Please do the following to update:

1. Extract the backup_all_1.1.2 script from your 1.2.0 admin tools package. You find it under src/scripts/.
2. Run it like your usual RSBAC backup under a 1.1.2 kernel with 1.1.2 tools and save the output script into a file.
3. Install version 1.2.0 and boot it in maintenance or soft mode.
4. Run the previously created restore script.
5. Reboot without maintenance or soft mode (or just switch the latter off).

Your 1.2.0 system should now behave as the 1.1.2 system before.

Please note that because of the changed attribute dir name from /rsbac to /rsbac.dat, you can have both versions installed in parallel and use them in turns. However, you should make sure that the other version's dirs are always properly protected against modification and that you always use the correct versions of the admin tools.

#### Other Versions

If you upgraded your RSBAC version and the data structure for a list type has changed, a warning message will be printed. The data will usually be converted from the older version and booting will continue as usual. However, from very old versions or corrupted files the data might 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 or via softmode, 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. This can also happen with the (optional) sys_read/write interception (from v1.1.1), because requests READ and WRITE to file and fifo targets were not cared for.

If you only plan to test a new version, without touching your old settings, it is advisable to enable the RSBAC_NO_WRITE option in the kernel configuration. In this case, the new version will only upgrade the settings in memory and never write any setting to disk. For single boots, the kernel parameter rsbac_debug_no_write will have the same effect.

### Kernel Parameters

Lilo

(Milo 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 full list and more info, optional means existence depending on kernel config):

- rsbac_debug_no_write: Turn writing to disk off for this single boot time. For testing.

rsbac_softmode (optional): Turn on soft mode. Useful for testing and learning and in emergency cases.
rsbac_dac_disable (optional): Disable Linux filesystem access control. Use with extreme care!
rsbac_nosyslog (optional): Turn off RSBAC logging to syslog for this boot time.
- 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 (attribute auth_may_setuid on file /bin/login). 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. Up to version 1.0.9a, `make install` also creates the file /rsbac/useraci, if necessary, that you need for booting and administration.

From 1.1.2, there is a ./configure script, which has to be run before the make. If your RSBAC kernel source tree does not reside in /usr/src/linux, use the --with-kerneldir option.

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.

In RSBAC versions prior to 1.0.9b, you must not have an RSBAC kernel active, not even a maintenance kernel, when installing the tools, because the useraci file has to be copied to /rsbac. From 1.0.9b, the kernel part automatically generates a standard user setup, if this file is missing.

When upgrading 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. Please read section Upgrading.

(Obsolete from v1.2.0) Until version 1.1.2, the menu tools require the dialog tool, which is part of most Linux distributions. 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. From v1.2.0, there is an extra rsbac_dialog tool included.

### 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 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
- attr_get_net: Read attribute values of NETDEV, NETTEMP and NETOBJ objects from General Data Structures. Parameters are module, target type (USER or PROCESS), attribute name and ids of objects whose attributes are to be read. Return values are numeric.
- attr_set_net: Change attribute values of NETDEV, NETTEMP and NETOBJ objects from General Data Structures. Parameters are module, target type (USER or PROCESS), attribute name, value and ids of objects whose attributes are to be set.
- attr_back_net: attribute backup for NETDEV and NETTEMP
- rsbac_stats: Return status in

formation 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. This tool can also switch soft mode on or off.
- mac_wrap: A wrapper for inetd etc. to reduce maximum security level for a process.
- rc_role_wrap: Wrapper to change to a compatible role before execution of a program.
- 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.
- rsu (new in 1.1.2): execute command with different role, does authentication checking
- linux2acl (new in 1.1.2): creates an ACL model administration script from existing Linux groups and filesystem object rights. Should be used, if Linux filesystem access control is meant to be replaced by ACL and disabled via rsbac_dac_disable (s.a.).
- 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.
- rsbac_acl_menu: A dialog menu based ACL administration tool
- rsbac_acl_group_menu: A dialog menu based ACL group administration tool
- rsbac_netdev_menu: Dialog menu for NETDEV attributes.
- rsbac_nettemp_menu: Dialog menu for NETTEMP attributes.
- rsbac_nettemp_def_menu: Dialog menu for Network Template definitions.

Apart from the Privacy Model, the Role Compatibility model, the AUTH model and the ACL model, administration of decision modules is only done via setting of general attributes. Those 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).

### 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/her 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.

Also, there are two dialog menu tools, rsbac_acl_menu and rsbac_acl_group_menu, which can make life much easier.

## 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 RC rights to 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).
- acl_rm_user (new in 1.0.9c): Remove everything in ACL related to a user
- linux2acl (new in 1.1.2): convert Linux groups and rights to ACL

## 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 or turn on softmode - if you configured the kernel not to switch, you must reboot with a maintenance kernel. For obvious reasons, it is recommended to down all network interfaces before turning off access control.

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.

An RC restore script is produced with 'rc_get_item backup',

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. Please note that all users have to backup their own group lists with members, as the other users have no access to them. From 1.1.2, they can use the acl_backup_my_groups script in the admin tools examples/acl/ dir.

The admin tools include a script backup_all, which tries to produce a backup script of almost all RSBAC settings for all modules except PM (see below). Again, ACL group backup is not possible this way - either let all users backup their groups or copy the proc backup files aclgm and aclgrp in /proc/rsbac-info/backup.

Then you can use normal tar etc. commands to backup the files. If you are using the PM module, you should also copy /proc/rsbac-info/backup/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 on different systems 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. If you are using ACL, you can copy the aclgrp and aclgm files into /rsbac. All other settings are restored by running the restore scripts. Please note that ACL groups have to be restored by their original owners, or they will be owned be the user running the restore. Alternatively, the restore user can later transfer ownership.

## 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.

Some other examples are in the Examples document.

Back to RSBAC homepage

- Questions, tips, etc.

28-May-02, -ao