Releases

Current version
Git/Latestdiff: 1.5.6

Latest Snapshots
Produced after each commit or rebase to new upstream version

GIT
RSBAC source code, can be unstable sometimes

Events

No events planned

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

--- wiki:experiences:telmich [2006/01/11 13:50] – 217.14.64.50
+++ wiki:experiences:telmich [2006/05/02 13:40] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== general impression ======
+  * Looks like RSBAC is still in a stable state
+  * Looks like the documentation is still ** very to little **
+  * motivated developers
+  * small community (still)
+  * still unknown to many people out there
+====== TODO ======
+Things I want to achieve / do with RSBAC:
+  - Create a new user, who
+    - may create, delete and modify other users (like a end user compatible user manager)
+  - Understand and use PM (there is no "real" documentation!)
+  - Create a new user, who can shutdown / reboot the system
+  - use jails
+  - use rsbac_mod for apache, as soon as vhosts are supported
+  - test daemons, check whether they can run with rsbac
+  - test cinit with RSBAC
+====== common problems ======
+===== su / setuid =====
+When you enabled ssh (see below) you may be able to **directly** login as //you// or **root**, but using __su__
+or __sudo__ may fail, because you are normally **not** allowed to setuid (to change) to another user.
+===== upgrading your system =====
+When you upgrade your system (especially ssh, login or pam) you may lose complete control
+over your system. Like I did some seconds ago:
+  - I logged in as root
+  - I typed "apt-get update && apt-get dist-upgrade"
+  - I went away, shopping for the company
+  - I came back and wanted to login as "rsbac_400"
+  - The answer was "setuid: Operation not permitted"
+What happened?
+  - The update saw that there are new packages and dist-upgrade installs them
+  - The dist upgrade replaced ///bin/login//
+  - The inode of /bin/login changed
+  - The old settings for /bin/login vanished
+  - I am not able to login anymore
+  - sshd also got replaced, so the connection is reseted by the rsbac host
+**How to solve the problem**
+  - I am right now trying it...
+  - I rebooted the system
+  - At the grub prompt I added //rsbac_auth_enable_login// as kernel parameter
+  - Now I am able to login as rsbac_400 on the console (at least in theory it still boots)
+  - And now I can restore the standard settings:
+     - Allow /bin/login to setuid (use //rsbac_fd_menu /bin/login//)
+     - Allow /usr/sbin/sshd to setuid to everybody (no role implemented for ssh yet)
+====== HOWTO ======
+===== Migrating 'bruehe.schottelius.org' =====
+  - get vanilla Linux kernel
+  - configure standard kernel
+  - install and test standard kernel
+  - try to add the rsbac-patch to kernel (bunzip2 //patchname// | patch -p1 --dry-run)
+  - add the rsbac-patch to kernel (bunzip2 //patchname// | patch -p1)
+  - add rsbac-common (tar xfj rsbac-common*.tar.bz2 in /usr/src/linux)
+  - configure the new kernel options (RSBAC Menu), build it
+    - Be sure to select UM (user management), because we want exclusive in-kernel user management later
+  - extract //rsbac-admin// somewhere else (/usr/src perhaps), build it (make build), install it (make install)
+  - add special user //rsbac_400// (//useradd -m rsbac_400//) and give it a password (//passwd rsbac_400//)
+  - add the new kernel to the bootloader and add the following kernel option: //rsbac_auth_enable_login//
+    - This will let you login, otherwise login is denied to do setuid (like any other program)
+  - reboot
+  - I was able to login on the prompt now :)
+==== getting sshd running ====
+Because **bruehe.schottelius.org** is my home webserver / router, I wanted to administrate it from work so I can continue to configure it with rsbac. So the first thing which had/has to run is ssh. ssh was a little bit tricky on my testing machine **dosinux**, so I took the easy way and allowed sshd to setuid to anybody (this is a security problem, because exploiting sshd could compromise the system now!).
+Anyway, we'll get more secure later.
+  - login as rsbac_400
+  - call //rsbac_fd_menu /usr/sbin/sshd//
+  - select //AUTH May Setuid// and set it to //1 / On//
+  - now you should be able to use ssh
+==== migrating users and groups to rsbac management ====
+When converting users and groups you have to keep in mind, that you **CANNOT** convert the old passwords! They are encrypted on disk and rsbac **CANNOT** (and does not want to, it is not a password cracker) decrypt them. So you have to setup the passwords in RSBAC, after you converted the users.
+  - login as rsbac_400 (through ssh or local, does not matter)
+  - convert users: //rsbac_useradd -O//
+  - convert groups: //rsbac_groupadd  -O//
+  - setup password for **AT LEAST** root and rsbac_400
+    - **DO THAT AS RSBAC_400, root may not have enough priviliges yet!**
+    - use //rsbac_passwd -n//, which will NOT ask for the old password
+    - the problem is that there IS no old password, so RSBAC will **always** fail, if you omit -n
+   - When you try to use rsbac_passwd as root, the following may happen:<code>
+bruehe2# dmesg -c &>/dev/null
+bruehe2# rsbac_passwd -n nico
+New RSBAC password for user nico (uid 1000):
+Repeat new password:
+Error: Operation not permitted
+bruehe2# dmesg
+0000007472|rsbac_adf_request(): request MODIFY_PERMISSIONS_DATA, pid 1577, ppid 1078,
+prog_name rsbac_passwd, prog_file /usr/local/bin/rsbac_passwd, uid 0, target_type USER,
+tid 1000, attr none, value none, result NOT_GRANTED by MAC FF RC AUTH ACL
+</code>
+  - configure /etc/nsswitch.conf to use rsbac: remove the standard passwd/group/shadow lines and replace them by the following:
+    - ''passwd:         rsbac''
+    - ''group:          rsbac''
+    - ''shadow:         rsbac''
+  - It should now be possible to use //ls -l /home// and see the user names, which are now coming from rsbac:<code>
+bruehe2# ls -l /home/user
+[...]
+drwxr-xr-x   4 nico   nico        93 Jul 26 14:55 archiv
+drwxr-xr-x   5 fabian users      121 Nov  8 14:31 fabian
+drwxr-xr-x  10 julia  users     4096 Aug 11 15:03 julia
+drwxr-xr-x  56 nico   nico    106496 Nov 15 00:36 nico
+[...]</code>
+  - **AT THIS POINT BE SURE TO BE LOGGED IN AS ROOT AND RSBAC_400**
+  - configure pam to use rsbac: edit
+    - /etc/pam.d/common-account
+    - /etc/pam.d/common-password
+    - /etc/pam.d/common-auth
+    - /etc/pam.d/common-session
+    - and replace //pam_unix.so// with //pam_rsbac.so//
+  - **MAKE SURE YOU ARE LOGGED IN AS ROOT AND RSBAC_400 BEFORE YOU DID THAT CHANGE ABOVE**
+  - Now try to login (either via ssh if configured or via login)
+  - If it works: Gratulation, if not, join #RSBAC on irc.freenode.org and ask for help, **DO NOT LOGOUT ROOT OR RSBAC_400**
+So far so fine, we've rsbac user management running. Now, to proof it, let us remove the old authentication tokens: Move away
+  - /etc/passwd
+  - /etc/shadow
+  - /etc/group
+  - /etc/gshadow
+That's how I did it:
+<code>
+bruehe2# mkdir ~/old-unix/
+bruehe2# mv /etc/passwd /etc/shadow /etc/group /etc/gshadow ~/old-unix
+</code>
+And now, try to login again. Nice, isn't it?
+Now, at the end, do ultimo and **remove support** for normal authentication:
+<code>
+  - Rule Set Based Access Control (RSBAC)
+    - User Management  --->
+      - [*]   Exclusive user management
+</code>
+  - recompile
+  - reinstall
+  - reboot
+  - try to login, otherwise search for help :-) (or use softmode)
+==== securing sshd ====
+After we finished migrating to in kernel user management, we'll focus on securing the sshd.
+==== configuring squid (http proxy) ====
+  - try to start it, get errors in dmesg<code>
+bruehe2# dmesg -c
+bruehe2# /etc/init.d/squid start
+Starting proxy server: start-stop-daemon: Unable to set uid to root (Operation not permitted)
+squid.
+bruehe2# dmesg
+0000007633|rsbac_adf_request(): request CHANGE_OWNER, pid 6662, ppid 6657, prog_name
+start-stop-daem, prog_file /sbin/start-stop-daemon, uid 0, target_type PROCESS, tid 6662,
+attr owner, value 0, result NOT_GRANTED by AUTH
+</code>
+  - See that Debian sys-v-init scripts aren't the best thing :/
+  - start squid manually<code>
+bruehe2# /usr/sbin/squid
+bruehe2# dmesg -c
+0000007645|rsbac_adf_request(): request READ, pid 6681, ppid 1078, prog_name squid,
+prog_file /usr/sbin/squid, uid 0, target_type GROUP, tid 13, attr none, value none, result
+NOT_GRANTED by RC ACL
+0000007646|rsbac_adf_request(): request READ, pid 6684, ppid 6682, prog_name squid,
+prog_file /usr/sbin/squid, uid 0, target_type GROUP, tid 13, attr none, value none, result
+NOT_GRANTED by RC ACL
+0000007647|rsbac_adf_request(): request CHANGE_OWNER, pid 6684, ppid 6682, prog_name squid,
+prog_file /usr/sbin/squid, uid 0, target_type PROCESS, tid 6684, attr owner, value 13,
+result NOT_GRANTED by AUTH
+0000007648|rsbac_adf_request(): request READ, pid 6686, ppid 6682, prog_name squid,
+prog_file /usr/sbin/squid, uid 0, target_type GROUP, tid 13, attr none, value none, result
+NOT_GRANTED by RC ACL
+0000007649|rsbac_adf_request(): request CHANGE_OWNER, pid 6686, ppid 6682, prog_name squid,
+prog_file /usr/sbin/squid, uid 0, target_type PROCESS, tid 6686, attr owner, value 13,
+result NOT_GRANTED by AUTH
+</code>
+  - give /usr/sbin/squid the AUTH Capability to change to user 'proxy' (id 13 as seen in the errors)
+  - login as rsbac_400
+  - call rsbac_fd_menu /usr/sbin/squid
+  - go to AUTH Capability
+  - add '13' (or whatever your proxy uid is)
+  - call /usr/sbin/squid
+  - That's how it worked here
+==== configuring apache (http server) ====
+[[http://trusteddebian.org/Members/tsauter/rsbac-apache-rc.txt/view]]
+==== configuring openvpn (vpn server) ====
+==== configuring screen (console "server") ====
+The following will happen, if you did not configure it before:
+<code>
+bruehe2# dmesg -c &>/dev/null
+bruehe2# screen -l
+[screen is terminating]
+bruehe2# dmesg
+0000007473|rsbac_adf_request(): request CHANGE_OWNER, pid 1596, ppid 1595, prog_name screen,
+prog_file /usr/bin/screen, uid 0, target_type PROCESS, tid 1596, attr owner, value 0, result
+NOT_GRANTED by AUTH
+0000007474|rsbac_adf_request(): request CHANGE_OWNER, pid 1594, ppid 1078, prog_name screen,
+prog_file /usr/bin/screen, uid 0, target_type PROCESS, tid 1594, attr owner, value 0, result
+NOT_GRANTED by AUTH
+bruehe2# ls -l /usr/bin/screen
+-rwxr-sr-x  1 root utmp 306616 Nov 14  2004 /usr/bin/screen
+</code>
+Doing the same as user //nico// produces the following error:
+<code>
+bruehe2# dmesg
+0000007526|rsbac_adf_request(): request CHANGE_OWNER, pid 1630, ppid 1621, prog_name screen,
+prog_file /usr/bin/screen, uid 1000, target_type PROCESS, tid 1630, attr owner, value 1000,
+result NOT_GRANTED by AUTH
+0000007527|rsbac_adf_request(): request CHANGE_OWNER, pid 1632, ppid 1631, prog_name screen,
+rog_file /usr/bin/screen, uid 1000, target_type PROCESS, tid 1632, attr owner, value 1000,
+result NOT_GRANTED by AUTH
+</code>
+This looks like beeing easy to solve: screen wants to setuid to the calling user.
+  - login as rsbac_400
+  - call //rsbac_fd_menu /usr/bin/screen//
+  - select //AUTH Capabilities// and then add //4294967293// (user who started the program)
+That's it!
+==== configuring qmail (mta) ====
+==== configuring vsftpd (ftp server) ====
+# add user ftp, give correct homedir: <code>
+rsbac_400@dosinux:~$ rsbac_useradd ftp
+rsbac_400@dosinux:~$ rsbac_usermod  -d /home/server/ftp ftp
+root@dosinux# mkdir -p /home/server/ftp
+root@dosinux# chown ftp /home/server/ftp
+</code>
+# now the following will happen:<code>
+dosinux# telnet localhost 21
+Trying 127.0.0.1...
+Connected to localhost.localdomain.
+Escape character is '^]'.
+OOPS: setuid
+OOPS: child died
+dosinux# dmesg
+0000000663|rsbac_get_attr(): auto-mounting device 00:04
+0000000664|rsbac_adf_request(): request CHANGE_OWNER, pid 8308, ppid 8307, prog_name vsftpd,
+prog_file /usr/sbin/vsftpd, uid 0, remote ip 81.163.253.243, target_type PROCESS, tid 8308,
+attr owner, value 65534, result NOT_GRANTED by AUTH
+0000000665|rsbac_adf_request(): request CHANGE_OWNER, pid 8318, ppid 8317, prog_name vsftpd,
+prog_file /usr/sbin/vsftpd, uid 0, remote ip 127.0.0.1, target_type PROCESS, tid 8318, attr
+owner, value 65534, result NOT_GRANTED by AUTH
+0000000666|rsbac_adf_request(): request CHANGE_OWNER, pid 8499, ppid 8498, prog_name vsftpd,
+prog_file /usr/sbin/vsftpd, uid 0, remote ip 127.0.0.1, target_type PROCESS, tid 8499, attr
+owner, value 65534, result NOT_GRANTED by AUTH
+</code>
+# You need to add at least the capability 65534 (nobody)
+# I also added capability 2002 (ftp), but did not test if it works without
+# Retest<code>
+dosinux# telnet localhost 21
+Trying 127.0.0.1...
+Connected to localhost.localdomain.
+Escape character is '^]'.
+Welcome to !eof - dosinux - RSBAC
+USER ANONYMOUS
+Please specify the password.
+PASS ae
+OOPS: vsftpd: refusing to run with writable anonymous root
+OOPS: cap_set_proc
+Connection closed by foreign host.
+dosinux# chmod u-w /home/server/ftp
+dosinux# mkdir /home/server/ftp/upload
+dosinux# chown ftp /home/server/ftp/upload
+dosinux# dmesg -c
+0000000668|rsbac_adf_request(): request MODIFY_SYSTEM_DATA, pid 8529, ppid 8527, prog_name vsftpd, prog_file /usr/sbin/vsftpd, uid 65534, remote ip 127.0.0.1, target_type SCD, tid capability, attr none, value none, result NOT_GRANTED by MAC RC ACL
+</code>
+==== configuring bind9 (dns server) ====
+  - nothing to do if you want to run it as root. **YOU DO NOT WANT TO DO THAT!!**<code>
+bruehe2# # this would work, but you really do not want to do that.
+bruehe2# /usr/sbin/named</code>
+  - What we want to do is running named as user //bind//:<code>
+bruehe2# dmesg -c
+bruehe2# /usr/sbin/named -u bind
+named: setuid(): Operation not permitted
+bruehe2# dmesg
+0000007923|rsbac_adf_request(): request CHANGE_OWNER, pid 7043, ppid 1078, prog_name named,
+prog_file /usr/sbin/named, uid 0, target_type PROCESS, tid 7043, attr owner, value 103, result
+NOT_GRANTED by AUTH
+</code>
+  - Allow named to become user //bind//
+  - login as rsbac_400
+  - rsbac_fd_menu /usr/sbin/named
+  - Add AUTH Capability //bind//
+  - let us retry:<code>
+bruehe2# /usr/sbin/named -u bind
+named: capset failed: Operation not permitted
+bruehe2# dmesg
+0000007924|rsbac_adf_request(): request MODIFY_SYSTEM_DATA, pid 7215, ppid 1078, prog_name
+named, prog_file /usr/sbin/named, uid 103, target_type SCD, tid capability, attr none, value
+none, result NOT_GRANTED by MAC PM RC ACL
+</code>
+  - Now I read http://rsbac.info/documentation/targets_and_requests to understand what SCD means
+  - After that I read http://rsbac.info/documentation/different_models/rc to understand the RC model
+  - Now create a new Role for Bind
+    - login as rsbac_400
+    - call rsbac_rc_role_menu
+    - press cancel
+    - scroll to bottom
+    - choose "New Role"
+    - give it some number and some name
+    - go to Type Comp SCD
+    - select capability
+    - select MODIFY_SYSTEM_DATA
+    - leave menu
+  - Now let /usr/sbin/named use this new role
+    - login as rsbac_400
+    - call rsbac_fd_menu /usr/sbin/named
+    - choose RC Force Role and select the newly created role
+  - Now we have many new errors, which I'll have a look at after I slept ;-)
+    - those errors can be found in http://creme.schottelius.org/~nico/linux/debug/rsbac/dmesg.rsbac.bind-u-bind
+  - I've found a way to remove most of them
+    - in the rc_role_menu, when editing the named role, give it role compatibility to Role 0, General user. Than there is only one error left:<code>
+0000009595|rsbac_adf_request(): request MODIFY_SYSTEM_DATA, pid 16229, ppid 27310,
+prog_name named, prog_file /usr/sbin/named, uid 103, target_type SCD, tid capability, attr
+none, value none, result NOT_GRANTED by MAC PM RC ACL
+</code>
+  - I was told that I should have copied the "General User Role" to my role to make my life easier. So I did that and named the role "named (copied)" See what happens now:<code>
+bruehe2# named -u bind
+named: capset failed: Operation not permitted
+named: capset failed: Operation not permitted
+bruehe2# dmesg
+0000009605|rsbac_adf_request(): request MODIFY_SYSTEM_DATA, pid 19268, ppid 27310,
+prog_name named, prog_file /usr/sbin/named, uid 0, target_type SCD, tid capability, attr
+none, value none, result NOT_GRANTED by RC
+0000009606|rsbac_adf_request(): request MODIFY_SYSTEM_DATA, pid 19268, ppid 27310,
+prog_name named, prog_file /usr/sbin/named, uid 103, target_type SCD, tid capability, attr
+none, value none, result NOT_GRANTED by MAC PM RC ACL</code>
+  - now I allow this role to use capability, in SCD, to MODIFY_SYSTEM_DATA; now this happens:<code>
+bruehe2# killall named
+bruehe2# named -u bind
+named: capset failed: Operation not permitted
+bruehe2# dmesg -c
+0000009613|rsbac_adf_request(): request MODIFY_SYSTEM_DATA, pid 19951, ppid 27310,
+prog_name named, prog_file /usr/sbin/named, uid 103, target_type SCD, tid capability, attr
+none, value none, result NOT_GRANTED by MAC PM ACL
+</code>
+  - now I am a bit confused, because I do not see the differnce between the error I removed and the error still exists. Only that other modules still deny it, where RC allows it. But why do MAC, PM and ACL deny THIS request and ALLOW the one before?
+  - found the difference: the first error occurs as root, while the second occurs as user 103 (bind)
+  - I think the reason for this is: in rsbac_fd_menu I added the AUTH capability 103, that means to switch to bind
+  - Then as user bind the RC does not fit|work|is not usable anymore
+  - The question is, what is the correct way to fix it. Perhaps it is possible to add the AUTH capability to the 'named (copied)' role and perhaps this will work.
+==== configuring oidentd (identd server) ====
+  - When starting oidentd normally, it starts, but rsbac gives the following error:<code>
+0000009630|rsbac_adf_request(): request READ, pid 21155, ppid 27310, prog_name oidentd,
+prog_file /usr/sbin/oidentd, uid 0, target_type GROUP, tid 65534, attr none, value none,
+result NOT_GRANTED by RC ACL</code>
+==== configuring cinit (init system)  ====
+==== configuring silcd (chat server)  ====
+  - create group silc: rsbac_400@bruehe2:~$ rsbac_groupadd silc
+  - create user silc in group silc: rsbac_400@bruehe2:~$ rsbac_useradd  -g silc silc
+  - tell silcd in silcd.conf to use user silc and group silc
+  - add auth capability "silc"
+  - now trying to start:<code>
+bruehe2# /usr/packages/silc-1.0.1/sbin/silcd -f /usr/packages/silc-1.0.1/etc/silcd.conf
+bruehe2# dmesg
+0000009616|rsbac_adf_request(): request READ, pid 20550, ppid 20549, prog_name silcd,
+prog_file /usr/packages/silc-1.0.1/sbin/silcd, uid 0, target_type GROUP, tid 2000, attr none,
+value none, result NOT_GRANTED by RC ACL
+</code>
+  - and it works perfectly, although this read is denied!
+  - now add group capability to group "silc"
+  - this **fails** with the error RSBAC_EWRITEFAILED. I've to find out why there is this error
+==== creating a user/group administrator  ====
+===== dosinux.schottelius.org =====
+==== configuring apache2 (http server) ====
+  - Do apt-get install apache2 before
+  - See what happens:<code>
+dosinux# /usr/sbin/apache2
+dosinux# dmesg
+0000001236|rsbac_adf_request(): request READ, pid 3517, ppid 2735, prog_name apache2,
+prog_file /usr/sbin/apache2, uid 0, target_type GROUP, tid 33, attr none, value none, result
+NOT_GRANTED by RC ACL
+0000001237|rsbac_adf_request(): request READ, pid 3518, ppid 3517, prog_name apache2,
+prog_file /usr/sbin/apache2, uid 0, target_type GROUP, tid 33, attr none, value none,
+result NOT_GRANTED by RC ACL
+0000001238|rsbac_adf_request(): request CHANGE_OWNER, pid 3519, ppid 3518, prog_name
+apache2, prog_file /usr/sbin/apache2, uid 0, target_type PROCESS, tid 3519, attr owner,
+value 33, result NOT_GRANTED by AUTH
+0000001239|rsbac_adf_request(): request CHANGE_OWNER, pid 3520, ppid 3518, prog_name
+apache2, prog_file /usr/sbin/apache2, uid 0, target_type PROCESS, tid 3520, attr owner,
+value 33, result NOT_GRANTED by AUTH
+0000001240|rsbac_adf_request(): request CHANGE_OWNER, pid 3521, ppid 3518, prog_name
+apache2, prog_file /usr/sbin/apache2, uid 0, target_type PROCESS, tid 3521, attr owner,
+value 33, result NOT_GRANTED by AUTH
+0000001241|rsbac_adf_request(): request CHANGE_OWNER, pid 3522, ppid 3518, prog_name
+apache2, prog_file /usr/sbin/apache2, uid 0, target_type PROCESS, tid 3522, attr owner,
+value 33, result NOT_GRANTED by AUTH
+0000001242|rsbac_adf_request(): request CHANGE_OWNER, pid 3523, ppid 3518, prog_name
+apache2, prog_file /usr/sbin/apache2, uid 0, target_type PROCESS, tid 3523, attr owner,
+value 33, result NOT_GRANTED by AUTH
+</code>
+  - Add the AUTH capability 33 (www-data), use rsbac_400 and rsbac_fd_menu /usr/sbin/apache2
+  - TADA, it runs:<code>
+dosinux# /usr/sbin/apache2
+dosinux# dmesg
+0000001243|rsbac_adf_request(): request READ, pid 3692, ppid 2718, prog_name apache2, prog_file /usr/sbin/apache2, uid 0, target_type GROUP, tid 33, attr none, value none, result NOT_GRANTED by RC ACL
+0000001244|rsbac_adf_request(): request READ, pid 3693, ppid 3692, prog_name apache2, prog_file /usr/sbin/apache2, uid 0, target_type GROUP, tid 33, attr none, value none, result NOT_GRANTED by RC ACL
+dosinux# ps axu | grep apache2
+root      3693  0.8  0.9  16744  5436 ?        Ss   16:02   0:00 /usr/sbin/apache2
+www-data  3694  0.0  0.9  16744  5456 ?        S    16:02   0:00 /usr/sbin/apache2
+www-data  3695  0.0  0.9  16744  5456 ?        S    16:02   0:00 /usr/sbin/apache2
+www-data  3696  0.0  0.9  16744  5456 ?        S    16:02   0:00 /usr/sbin/apache2
+www-data  3697  0.0  0.9  16744  5456 ?        S    16:02   0:00 /usr/sbin/apache2
+www-data  3698  0.0  0.9  16744  5456 ?        S    16:02   0:00 /usr/sbin/apache2
+root      3701  0.0  0.0   1520   328 pts/0    R+   16:02   0:00 grep apache2
+</code>
+===== Roles =====
+Roles should make life easier, currently they are just making my life more complicated. Let's see what we can do with them.
+==== creating a "user_manager" ====
+The first problem to solve with Roles is to create a user, which is able to
+  - create
+  - delete
+  - and modify other users (like a end user compatible user manager)
+First of all, I create a user:
+  - login as rsbac_400, do <code>rsbac_useradd -d /home/user/user_manager user_manager</code>
+  - now do <code>rsbac_passwd -n user_manager</code>
+  - login as root and do<code>
+mkdir /home/user/user_manager
+chown user_manager ~user_manager</code>
+  - Now we successfully created a normal user.
+  - TOBEDONE...
+===== Backup =====
+==== all configurations ====
+==== users and groups ====
+===== Maintaining =====
+==== Problems updating the system ====
+When you update your system <code>apt-get update && apt-get-dist-upgrade</code>
+in Debian for instance, your RSBAC settings will party be **LOST**.
+Why that? Files are replaced and as far as I know RSBAC remembers the file by its inode. The inode will/may change after an update, so you loose the settings.
+To save your data you could first backup the settings, then update the sytem and then reply the settings.
+The problem I had was that I did a dist-upgrade and then squid was unable to start, because the settings I made with rsbac_fd_menu were lost.

//