<?php
include_once("../header.php");
?>
<div class="documentation">
<h2>Installation and Administration</h2>
<p>RSBAC sources come in three parts:
<ol>
<li>kernel extensions in the <a href="code/index.htm">rsbac-*.tar.gz</a> files</li>
<li>kernel patches to connect them to the kernel in the <a href="code/index.htm">patch-x.y.z.gz</a>
files</li>
<li>administration tools in the <a href="code/index.htm">rsbac-admin-*.tar.gz</a> files,
that have to be installed seperately.</li>
</ol>
<p>All sources can be downloaded via Internet from the RSBAC Homepage at <a
href="http://www.rsbac.org">http://www.rsbac.org</a>.</p>
<p>For beginners, there is also a good <a href="http://linux.ru.net/~inger/RSBAC-DOC.html">RSBAC
for Beginners</a> page on <a href="http://linux.ru.net">linux.ru.net</a>.</p>
<h2>The Kernel</h2>
<h3>Installation</h3>
<h4>Quick Install:</h4>
<p>To install RSBAC version A.B.C with kernel version X.Y.Z do:
<ol>
<li>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 <a href="ftp://ftp.kernel.org">ftp.kernel.org</a>
mirror, rsbac-vA.B.C.tar.bz2, patch-X.Y.Z-vA.B.C.gz from <a
href="http://www.rsbac.org/code">www.rsbac.org/code</a> or <a
href="http://www.rsbac.org/pre">www.rsbac.org/pre</a>. Alternatively, you can download a
pre-patched kernel from <a href="http://www.rsbac.org/kernels">www.rsbac.org/kernels</a>
(FTP mirror at <a href="ftp://rsbac.cz/mirrors/rsbac.org/kernels/">ftp://rsbac.cz/mirrors/rsbac.org/kernels/</a>),
unpack it and go to step 6.</li>
<li>Unpack kernel source tree: tar xvIf linux-X.Y.Z.tar.bz2</li>
<li>cd linux</li>
<li>Unpack RSBAC tar archive: tar xvIf ../rsbac-vA.B.C.bz2</li>
<li>Patch the kernel (and possibly some RSBAC files): gzip -dc ../patch-X.Y.Z-vA.B.C.gz |
patch -p1</li>
<li>Download all bugfixes for this RSBAC release from <a
href="http://www.rsbac.org/bugfixes/">www.rsbac.org/bugfixes/</a>
and apply them in the same manner, e.g.: cat rsbac-bugfix-vX.Y.Z-N | patch
-p1. </li>
<li>make menuconfig</li>
<li>touch Makefile</li>
<li>make dep bzImage modules modules_install</li>
<li>Install the new kernel arch/<arch-name>/boot/bzImage with your favourite boot
loader.</li>
</ol>
<h4>Detailed Version:</h4>
<p>For installation you must have the kernel source tree in a supported version installed.
You can get it in an archive called <em>linux-2.x.y.tar.gz</em>. The archive can be
extracted in the directory <em>/usr/src</em> using the command <kbd>tar xvzf
linux-2.x.y.tar.gz</kbd>. This will create a subdirectory <em>linux</em> that should be
renamed to e.g. <em>linux-2.x.y-rsbac</em> just to avoid errors later. If a file or
directory called <em>linux</em> exists, those must be removed or renamed first. You will
need at least 130 MB for the 2.2.21 kernel sources and 220 MB for the 2.4.19 kernel
sources, including RSBAC and object files.</p>
<h4>a) (OLD!) Applying the big patch (old distribution as big patch, up to v1.0.8a)</h4>
<p>After that <em>rsbac-patch-*.gz</em> can be decompressed by <kbd>gzip -d
rsbac-patch-*.gz</kbd>. You should move the file <em>rsbac-patch-*</em> into <em>/usr/src</em>
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 <em>/usr/src/linux-2.2.xxx-rsbac</em>
by typing <br>
<kbd>patch -p1 </usr/src/rsbac-patch-* &>/usr/src/err</kbd><br>
When the patch has finished, you find a protocol in <em>/usr/src/err</em>. If there are
any rejects (look for <em>failed</em> in the protocol), you should delete the entire
source tree and retry. If it still does not work, please give <a
HREF="mailto:ao@rsbac.org">me</a> or the <a HREF="mailto:rsbac@rsbac.org">RSBAC list</a> a
note - this is an error that should never happen! </p>
<p>If your kernel source has been changed before, rejects are more likely to happen. The
protocol and the files <em>*.rej</em> 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? </p>
<h4>b) Installing from tarball (from v1.0.9 on)</h4>
<p>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/.</p>
<p>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<br>
gzip -dc patch-x.y.z-va.b.c.gz | patch -p1 &>perr<br>
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.</p>
<p>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.</p>
<p>Patch changes for version:
<ul>
<li>1.0.9b</li>
<li>1.1.0</li>
<li>1.1.1</li>
<li>1.1.2</li>
<li>1.2.0</li>
<li>1.2.1</li>
<li>1.2.2</li>
<li>1.2.3</li>
<li>1.2.4</li>
</ul>
<h3>Kernel Configuration and Compilation</h3>
<p>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 <a
href="instadm.htm#backup">How to Backup</a>. 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 <a
href="#upgrading">Upgrading</a> below.</p>
<p>The kernel configuration is done as usual, e.g. by calling <kbd>make menuconfig</kbd>
in the source main directory. In the main menu another submenu called <em>Rule Set Based
Access Control</em> appears, in which you find too many choices to present them here.
Please see the configuration help for detailed descriptions. </p>
<p>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.</p>
<p>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.</p>
<p>After configuration the kernel is compiled as usual, e.g. using <kbd>make bzImage</kbd>,
and installed with <em>lilo</em>.</p>
<p>With RSBAC versions before 1.0.9b, you <strong>must</strong> install the administration
tools before reboot, specially the <em>useraci</em> file in it should go into <em>/rsbac</em>
(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 <em>useraci</em> is no
longer provided.</p>
<p>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.</p>
<p>(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.</p>
<h3>The First Boot</h3>
<p>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 <tt>rsbac_softmode</tt>, 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}.</p>
<p>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)<br>
<tt>rsbac rsbac_auth_enable_login<br>
</tt>If you forget this, you will not be able to login and have to reboot, e.g. via
CTRL-ALT-DEL.</p>
<p>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.</p>
<p>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<br>
<tt>rsbac_fd_menu <name-of-daemon-executable></tt><br>
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.</p>
<h3>Possible Problems / Maintenance Mode</h3>
<p>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.</p>
<p>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!</p>
<p>For Maintenance Mode, just turn it on in the RSBAC kernel configuration. This kernel
should be installed with <em>lilo</em> 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.</p>
<p>(Obsolete from 1.0.9b) In RSBAC versions up to 1.0.9a, if you get a message <em>rsbac_init():
User ACI could not be read</em> when booting and the system does not come up, the standard
<em>useraci</em> 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 <a href="contact.htm">RSBAC
mailing list</a>.</p>
<p>(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 <a href="../download/bugfixes/">bugfix</a> for this.<a NAME="kernparm"></p>
</a>
<p>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. </p>
<p>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 <em>rsbac_fd_menu filename</em>.</p>
<h3><a name="upgrading"></a>Upgrading RSBAC</h3>
<h4>From 1.1.2 to 1.2.0</h4>
<p>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:
<ol>
<li>Extract the backup_all_1.1.2 script from your 1.2.0 admin tools package. You find it
under src/scripts/.</li>
<li>Run it like your <a href="#backup">usual RSBAC backup</a> under a 1.1.2 kernel with
1.1.2 tools and save the output script into a file.</li>
<li>Install version 1.2.0 and boot it in maintenance or soft mode.</li>
<li>Run the previously created restore script.</li>
<li>Reboot without maintenance or soft mode (or just switch the latter off).</li>
</ol>
<p>Your 1.2.0 system should now behave as the 1.1.2 system before.</p>
<p>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.</p>
<h4>Other Versions</h4>
<p>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 <a HREF="instadm.htm#backup">backup</a> all attributes before first
reboot. </p>
<p>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 <a HREF="models.htm">models.htm</a>
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.</p>
<p>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.</p>
<h3><a NAME="kernparm"></a>Kernel Parameters</h3>
<p><em>Lilo</em> (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):
<ul>
<li>rsbac_debug_no_write: Turn writing to disk off for this single boot time. For testing. </li>
<li>rsbac_softmode (optional): Turn on soft mode. Useful for testing and learning and in
emergency cases.</li>
<li>rsbac_dac_disable (optional): Disable Linux filesystem access control. Use with extreme
care!</li>
<li>rsbac_nosyslog (optional): Turn off RSBAC logging to syslog for this boot time. </li>
<li>rsbac_debug_write: Debug messages from all attribute writing procedures. </li>
<li>rsbac_debug_auto: Debug messages from auto-write / rsbacd. Recommended to get an
overview of save-to-disk activities. </li>
<li>rsbac_auth_enable_login: Grant /bin/login full AUTH change owner permission (attribute
auth_may_setuid on file /bin/login). See above. </li>
</ul>
<h2>Administration Tools</h2>
<h3>Installation</h3>
<p>The administration tools in the <em>rsbac-admin-*.tar.gz</em> file can be extracted
into any directory, e.g. <em>/root/rsbac</em>, by typing <kbd>tar xvzf
rsbac-admin-*.tar.gz</kbd>. After changing the paths for kernel source main directory,
installation and man pages in the file <em>Makefile</em>, a simple <kbd>make</kbd> creates
the tools and <kbd>make install</kbd> installs them. <kbd>make allclean</kbd> cleans up
your directory afterwards. Up to version 1.0.9a, <kbd>make install</kbd> also creates the
file <em>/rsbac/useraci</em>, if necessary, that you need for booting and administration. </p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>(Obsolete only in v1.2.0) Except version 1.2.0, 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. In v1.2.0, there is an extra
rsbac_dialog tool included. From 1.2.1, you need at least <a href="dialog/">dialog version
0.9b</a>.</p>
<h3>General Administration</h3>
<p>General administration is done via command line tools or via dialog menues on top of
these. No RSBAC internal files can be directly accessed.</p>
<p>If you want to use the menues, you should first configure them with the
rsbac_settings_menu (new in 1.2.0), e.g. select the set of modules you want to use.
However, the menues will work correctly without configuration, you will just see a lot of
RSBAC_EINVALIDMODULE messages and some useless menu items. Please make sure that your
resulting /etc/rsbac.conf file is properly protected against tampering, e.g. by setting
the read-only FF file flag.</p>
<p>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.</p>
<p>Each tool prints a short help if called with insufficient parameters. The following
tools are currently provided:
<ul>
<li>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. </li>
<li>attr_get_file_dir: Newer version from v1.0.1, optimized for scripting </li>
<li>attr_back_fd: (Recursive) attribute backup for FILE/DIR </li>
<li>attr_back_dev: (Recursive) attribute backup for DEV </li>
<li>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. </li>
<li>attr_set_file_dir: Newer version from v1.0.1, optimized for scripting </li>
<li>attr_rm_fd: Reset all attributes of the target given. </li>
<li>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. </li>
<li>attr_get_user: Newer version for USER from v1.0.1, optimized for scripting </li>
<li>attr_back_user: (Recursive) attribute backup for USER </li>
<li>attr_get_process: Newer version for PROCESS from v1.0.1, optimized for scripting </li>
<li>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. </li>
<li>attr_set_user: Newer version for USER from v1.0.1, optimized for scripting </li>
<li>attr_set_process: Newer version for PROCESS from v1.0.1, optimized for scripting </li>
<li>attr_rm_user: Reset all attributes of the user given. </li>
<li>attr_get_ipc: New for IPC objects from v1.0.1, optimized for scripting </li>
<li>attr_set_ipc: New for IPC objects from v1.0.1, optimized for scripting </li>
<li>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.</li>
<li>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.</li>
<li>attr_back_net: attribute backup for NETDEV and NETTEMP</li>
<li>rsbac_stats: Return status information on General Data Structures via system log, level
KERN_INFO. </li>
<li>switch_adf_log: Set protocol level for a decision request. Parameters are request name
and level (0-2, see <a HREF="instadm.htm#kernparm">Kernel Parameters</a>). </li>
<li>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.</li>
<li>mac_wrap: A wrapper for inetd etc. to reduce maximum security level for a process. </li>
<li>rc_role_wrap: Wrapper to change to a compatible role before execution of a program.</li>
<li>rsbac_write: request the modified data structures to be written to disk. </li>
<li>rsbac_check: request the data structures to be checked for consistency. This can also
reduce list sizes, because unnecessary entries are deleted.</li>
<li>rsu (new in 1.1.2): execute command with different role, does authentication checking</li>
<li>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.).</li>
<li>rsbac_menu: A dialog menu based administration dispatcher. </li>
<li>rsbac_settings_menu: Change and save menu settings, e.g. list of supported modules.</li>
<li>rsbac_fd_menu: A dialog menu based FILE/DIR administration tool. </li>
<li>rsbac_dev_menu: A dialog menu based DEV administration tool. </li>
<li>rsbac_user_menu: A dialog menu based USER administration tool. </li>
<li>rsbac_process_menu: A dialog menu based PROCESS administration tool. </li>
<li>rsbac_ipc_menu: A dialog menu based IPC administration tool (removed in 1.2.0). </li>
<li>rsbac_dev_menu: A dialog menu based DEV administration tool. </li>
<li>rsbac_rc_role_menu: A dialog menu based RC role administration tool. </li>
<li>rsbac_rc_type_menu: A dialog menu based RC type administration tool.</li>
<li>rsbac_acl_menu: A dialog menu based ACL administration tool</li>
<li>rsbac_acl_group_menu: A dialog menu based ACL group administration tool</li>
<li>rsbac_netdev_menu: Dialog menu for NETDEV attributes.</li>
<li>rsbac_nettemp_menu: Dialog menu for NETTEMP attributes.</li>
<li>rsbac_nettemp_def_menu: Dialog menu for Network Template definitions.</li>
</ul>
<p>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 <em>Security Officer</em>, 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.</p>
<p>The RC module is administrated via attributes and role and type definitions using the
RC admin tools. </p>
<p>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.</p>
<p>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 <a HREF="models.htm">model
descriptions</a> and the syscall man pages. Exact syntax descriptions and numeric codes
for attribute values are included in their regarding tool help (call without parameters). </p>
<h3>Administration of the Privacy Module (PM)</h3>
<p>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. <em>security_officer</em>
for its function <em>set_role</em>. Unfortunately there is no menu based tool so far -
still seeking for volunteers... </p>
<p>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 <em>pm_role</em> 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 <br>
<kbd>attr_set_up USER pm_role system_administrator 0</kbd> <br>
<kbd>attr_set_up USER pm_role security_officer 400</kbd> <br>
<kbd>attr_set_up USER pm_role data_protection_officer 401</kbd> </p>
<p>To define and assign TP values, a TP manager must be defined and assigned his/her role
as well. </p>
<h3>Administration of the Role Compatibility Module (RC)</h3>
<p>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. </p>
<p>Before starting administration, be sure you understood the model description in <a
HREF="models.htm#rc">models.htm</a>. The use of the tools should then be straight forward.
</p>
<p>If the necessary role definitions have not been set for users root (0) and 400, boot a
maintenance kernel and call e.g. <br>
<kbd>attr_set_up USER rc_def_role 2 0</kbd> <br>
<kbd>attr_set_up USER rc_def_role 1 400</kbd> <br>
This example uses the pre-defined roles System Admin (2) and Role Admin (1). </p>
<h3>Administration of the Access Control Lists Module (ACL)</h3>
<p>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 <a href="models.htm#acl">model
description</a>. All others are strongly encouraged to read the model description before
changing anything.</p>
<p>Also, there are two dialog menu tools, rsbac_acl_menu and rsbac_acl_group_menu, which
can make life much easier.</p>
<h2>Other Programs</h2>
<p>The administration package also includes some other programs, which are described here.
Of course those are restricted by access control, too.
<ul>
<li>rsbac_pm: Complete administration of the PM module, see above. </li>
<li>rsbac_stats_pm: Return status information on PM data in Data Structures via system log,
level KERN_INFO. </li>
<li>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. </li>
<li>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. </li>
<li>rc_copy_role: to copy one RC role to another, this is the only official way to add a
role. </li>
<li>rc_get_item: Get an RC role or type entry item. </li>
<li>rc_set_item: Set an RC role or type entry item. </li>
<li>rc_role_wrap: Start a program with another RC role. </li>
<li>rc_get_eff_rights: Get your effective RC rights to a File/Dir/Dev target.</li>
<li>auth_set_cap: Add, remove and list process change owner capability sets for processes
and files. </li>
<li>auth_back_cap: Backup file capability sets, similar to attr_back_fd. </li>
<li>acl_rights: Show a subject's effective rights to an object.</li>
<li>acl_grant: Change a subject's rights to an object.</li>
<li>acl_mask: View or set an object's mask for right inheritance.</li>
<li>acl_tlist: Show a list of subjects with direct rights to an object (trustee list).</li>
<li>acl_rm_user (new in 1.0.9c): Remove everything in ACL related to a user</li>
<li>linux2acl (new in 1.1.2): convert Linux groups and rights to ACL</li>
<li>rsbac_jail (new in 1.2.1): Start programs in a JAIL.</li>
</ul>
<p><a name="backup"></a></p>
<h2>How to backup and restore</h2>
<p>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.</p>
<p>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.</p>
<p>If AUTH is enabled, you can use auth_back_cap to backup the file capabilities. </p>
<p>An RC restore script is produced with 'rc_get_item backup',</p>
<p>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.</p>
<p>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.</p>
<p>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. </p>
<p>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.</p>
<p>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.</p>
<h2>RSBAC Demonstration Examples</h2>
<p>For demonstration purposes a <a HREF="example_pm.htm#pm">simple Privacy Model (PM)
application example</a> has been developed together with <a
HREF="http://agn-www.informatik.uni-hamburg.de/people/fischer">Simone Fischer-Hübner</a>.
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.</p>
<p>Some other examples are in the <a href="examples.htm">Examples</a> document.</p>
</div>
<?php
include_once("../footer.php");
?>
