• 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

Things I want to achieve / do with RSBAC:

1. Create a new user, who
   1. may create, delete and modify other users (like a end user compatible user manager)
2. Understand and use PM (there is no “real” documentation!)
3. Create a new user, who can shutdown / reboot the system
4. use jails
5. use rsbac_mod for apache, as soon as vhosts are supported
6. test daemons, check whether they can run with rsbac
7. test cinit with RSBAC

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.

When you upgrade your system (especially ssh, login or pam) you may lose complete control over your system. Like I did some seconds ago:

1. I logged in as root
2. I typed “apt-get update && apt-get dist-upgrade”
3. I went away, shopping for the company
4. I came back and wanted to login as “rsbac_400”
5. The answer was “setuid: Operation not permitted”

What happened?

1. The update saw that there are new packages and dist-upgrade installs them
2. The dist upgrade replaced /bin/login
3. The inode of /bin/login changed
4. The old settings for /bin/login vanished
5. I am not able to login anymore
6. sshd also got replaced, so the connection is reseted by the rsbac host

How to solve the problem

1. I am right now trying it…
2. I rebooted the system
3. At the grub prompt I added rsbac_auth_enable_login as kernel parameter
4. Now I am able to login as rsbac_400 on the console (at least in theory it still boots)
5. And now I can restore the standard settings:
   1. Allow /bin/login to setuid (use rsbac_fd_menu /bin/login)
   2. Allow /usr/sbin/sshd to setuid to everybody (no role implemented for ssh yet)

1. get vanilla Linux kernel
2. configure standard kernel
3. install and test standard kernel
4. try to add the rsbac-patch to kernel (bunzip2 patchname | patch -p1 –dry-run)
5. add the rsbac-patch to kernel (bunzip2 patchname | patch -p1)
6. add rsbac-common (tar xfj rsbac-common*.tar.bz2 in /usr/src/linux)
7. configure the new kernel options (RSBAC Menu), build it
   1. Be sure to select UM (user management), because we want exclusive in-kernel user management later
8. extract rsbac-admin somewhere else (/usr/src perhaps), build it (make build), install it (make install)
9. add special user rsbac_400 (useradd -m rsbac_400) and give it a password (passwd rsbac_400)
10. add the new kernel to the bootloader and add the following kernel option: rsbac_auth_enable_login
    1. This will let you login, otherwise login is denied to do setuid (like any other program)
11. reboot
12. I was able to login on the prompt now :)

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.

1. login as rsbac_400
2. call rsbac_fd_menu /usr/sbin/sshd
3. select AUTH May Setuid and set it to 1 / On
4. now you should be able to use ssh

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.

1. login as rsbac_400 (through ssh or local, does not matter)
2. convert users: rsbac_useradd -O
3. convert groups: rsbac_groupadd -O
4. setup password for AT LEAST root and rsbac_400
   1. DO THAT AS RSBAC_400, root may not have enough priviliges yet!
   2. use rsbac_passwd -n, which will NOT ask for the old password
   3. the problem is that there IS no old password, so RSBAC will always fail, if you omit -n
5. When you try to use rsbac_passwd as root, the following may happen:

   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

6. configure /etc/nsswitch.conf to use rsbac: remove the standard passwd/group/shadow lines and replace them by the following:
   1. passwd: rsbac
   2. group: rsbac
   3. shadow: rsbac
7. It should now be possible to use ls -l /home and see the user names, which are now coming from rsbac:

   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
   [...]

8. AT THIS POINT BE SURE TO BE LOGGED IN AS ROOT AND RSBAC_400
9. configure pam to use rsbac: edit
   1. /etc/pam.d/common-account
   2. /etc/pam.d/common-password
   3. /etc/pam.d/common-auth
   4. /etc/pam.d/common-session
   5. and replace pam_unix.so with pam_rsbac.so
10. MAKE SURE YOU ARE LOGGED IN AS ROOT AND RSBAC_400 BEFORE YOU DID THAT CHANGE ABOVE
11. Now try to login (either via ssh if configured or via login)
12. 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

1. /etc/passwd
2. /etc/shadow
3. /etc/group
4. /etc/gshadow

That's how I did it:

bruehe2# mkdir ~/old-unix/
bruehe2# mv /etc/passwd /etc/shadow /etc/group /etc/gshadow ~/old-unix 

And now, try to login again. Nice, isn't it?

Now, at the end, do ultimo and remove support for normal authentication:

  - Rule Set Based Access Control (RSBAC) 
    - User Management  --->
      - [*]   Exclusive user management

1. recompile
2. reinstall
3. reboot
4. try to login, otherwise search for help (or use softmode)

After we finished migrating to in kernel user management, we'll focus on securing the sshd.

1. try to start it, get errors in dmesg

   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

2. See that Debian sys-v-init scripts aren't the best thing :/
3. start squid manually

   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

4. give /usr/sbin/squid the AUTH Capability to change to user 'proxy' (id 13 as seen in the errors)
5. login as rsbac_400
6. call rsbac_fd_menu /usr/sbin/squid
7. go to AUTH Capability
8. add '13' (or whatever your proxy uid is)
9. call /usr/sbin/squid
10. That's how it worked here

http://trusteddebian.org/Members/tsauter/rsbac-apache-rc.txt/view

The following will happen, if you did not configure it before:

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

Doing the same as user nico produces the following error:

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

This looks like beeing easy to solve: screen wants to setuid to the calling user.

1. login as rsbac_400
2. call rsbac_fd_menu /usr/bin/screen
3. select AUTH Capabilities and then add 4294967293 (user who started the program)

That's it!

# add user ftp, give correct homedir:

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 

# now the following will happen:

dosinux# telnet localhost 21
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
500 OOPS: setuid
500 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

# 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

dosinux# telnet localhost 21     
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 Welcome to !eof - dosinux - RSBAC
USER ANONYMOUS
331 Please specify the password.
PASS ae
500 OOPS: vsftpd: refusing to run with writable anonymous root
500 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

1. nothing to do if you want to run it as root. YOU DO NOT WANT TO DO THAT!!

   bruehe2# # this would work, but you really do not want to do that.
   bruehe2# /usr/sbin/named

2. What we want to do is running named as user bind:

   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

3. Allow named to become user bind
4. login as rsbac_400
5. rsbac_fd_menu /usr/sbin/named
6. Add AUTH Capability bind
7. let us retry:

   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

8. Now I read http://rsbac.info/documentation/targets_and_requests to understand what SCD means
9. After that I read http://rsbac.info/documentation/different_models/rc to understand the RC model
10. Now create a new Role for Bind
    1. login as rsbac_400
    2. call rsbac_rc_role_menu
    3. press cancel
    4. scroll to bottom
    5. choose “New Role”
    6. give it some number and some name
    7. go to Type Comp SCD
    8. select capability
    9. select MODIFY_SYSTEM_DATA
    10. leave menu
11. Now let /usr/sbin/named use this new role
    1. login as rsbac_400
    2. call rsbac_fd_menu /usr/sbin/named
    3. choose RC Force Role and select the newly created role
12. Now we have many new errors, which I'll have a look at after I slept
    1. those errors can be found in http://creme.schottelius.org/~nico/linux/debug/rsbac/dmesg.rsbac.bind-u-bind
13. I've found a way to remove most of them
    1. 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:

       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

14. 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:

    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

15. now I allow this role to use capability, in SCD, to MODIFY_SYSTEM_DATA; now this happens:

    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

16. 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?
17. found the difference: the first error occurs as root, while the second occurs as user 103 (bind)
18. I think the reason for this is: in rsbac_fd_menu I added the AUTH capability 103, that means to switch to bind
19. Then as user bind the RC does not fit|work|is not usable anymore
20. 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.

1. When starting oidentd normally, it starts, but rsbac gives the following error:

   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

1. create group silc: rsbac_400@bruehe2:~$ rsbac_groupadd silc
2. create user silc in group silc: rsbac_400@bruehe2:~$ rsbac_useradd -g silc silc
3. tell silcd in silcd.conf to use user silc and group silc
4. add auth capability “silc”
5. now trying to start:

   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

6. and it works perfectly, although this read is denied!
7. now add group capability to group “silc”
8. this fails with the error RSBAC_EWRITEFAILED. I've to find out why there is this error

1. Do apt-get install apache2 before
2. See what happens:

   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

3. Add the AUTH capability 33 (www-data), use rsbac_400 and rsbac_fd_menu /usr/sbin/apache2
4. TADA, it runs:

   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

Roles should make life easier, currently they are just making my life more complicated. Let's see what we can do with them.

The first problem to solve with Roles is to create a user, which is able to

1. create
2. delete
3. and modify other users (like a end user compatible user manager)

First of all, I create a user:

1. login as rsbac_400, do

   rsbac_useradd -d /home/user/user_manager user_manager

2. now do

   rsbac_passwd -n user_manager

3. login as root and do

   mkdir /home/user/user_manager
   chown user_manager ~user_manager

4. Now we successfully created a normal user.
5. TOBEDONE…

When you update your system

apt-get update && apt-get-dist-upgrade

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.