Can't login after enabling RBAC system

[Pedro]

Hi everyone,

I'm new to the grsecurity RBAC system.
I run a grsecurity patched kernel (3.2.55-grsec) on a Debian machine. I downloaded gradm from grsecurity.org and compiled it.
I did this on my machine:

$ sudo gradm -E

then I logged out.

After that, it was impossible for me to log in through ssh (this is a remote machine, so ssh is my only way to login).
Fortunately, a hard reboot solved the problem.

Any idea why this happened and how I can avoid this problem in the future?

Thanks for your help.

[spender]

Hi,

Take a look at your kernel logs before the system reset -- you should find the reason why you were unable to login. I wouldn't recommend running gradm -E from an unprivileged user account with sudo. Log in as root, run gradm -E then immediately authenticate to the admin role. You'll then be able to see what gets denied across the rest of the system (via dmesg) and fix up the policy. Other than that, you could start with full system learning instead.

-Brad

[Pedro]

Thanks for your reply.

I found this in my syslog (just changed my hostname, ip address and username)

Feb 25 12:24:46 rrrr kernel: [126452.027292] grsec: From 12.34.56.78: (default:D:/usr/sbin/sshd) denied open of /proc/10405/oom_score_adj for writing by /usr/sbin/sshd[sshd:10405] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/sshd[sshd:2205] uid/euid:0/0 gid/egid:0/0
Feb 25 12:24:46 rrrr kernel: [126452.207657] grsec: From 12.34.56.78: (default:D:/usr/sbin/sshd) denied open of /home/myusername/.ssh/authorized_keys2 for reading by /usr/sbin/sshd[sshd:10405] uid/euid:0/1000 gid/egid:0/1000, parent /usr/sbin/sshd[sshd:2205] uid/euid:0/0 gid/egid:0/0
Feb 25 12:25:54 rrrr kernel: [126520.483717] grsec: From 12.34.56.78: (default:D:/usr/sbin/sshd) use of CAP_KILL denied for /usr/sbin/sshd[sshd:10405] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/sshd[sshd:2205] uid/euid:0/0 gid/egid:0/0

How could I give sshd access to the required files in /proc, and also .ssh config files in users homes?
I don't understand what's the deal with the CAP_KILL problem.

Also, is there another way to use gradm than authenticate as root and then authenticate as a RBAC admin with a password? This doesn't seem very convenient for automating these tasks.

[mnalis]

How could I give sshd access to the required files in /proc, and also .ssh config files in users homes?
I don't understand what's the deal with the CAP_KILL problem.

you add to your /usr/bin/sshd subject

Code: Select all

/proc/*/oom_score_adj rw
/home/*/.ssh r
+CAP_KILL


if you want to allow just one (or few) users instead of all, you would use "/home/myusername/.ssh r" instead of "/home/*/.ssh r", of course. CAP_KILL is needed as sshd tries to kill some of it children sometimes (proxycommand, privseparation child etc)

Also, is there another way to use gradm than authenticate as root and then authenticate as a RBAC admin with a password? This doesn't seem very convenient for automating these tasks.

That is intentional.You should not use allmighty admin role for automating tasks (it would simply create another almighy account, which kills the whole point of removing priviileges from almighty "root" you had before grsec). If you need elevated privileges for some tasks, you should use:

1. special admin user role - for example for "webadmin" user can change apache configs:
   

   Code: Select all

   role webadmin u
subject /
  /etc/apache2 rwcdl


   
   
2. use subject inheritance - for example
   

   Code: Select all

   /usr/local/sbin/add_virtualhost:
echo blablabla > /etc/apache2/sites-available/$1.conf
/usr/bin/a2ensite $1

/etc/grsec/policy:
subject /usr/local/sbin/add_virtualhost
  /etc/apache2 rwcdl
  /usr/bin rxi


   
   (in this case /usr/bin/a2ensite too would run with rwcdl access to /etc/apache2 directory)
   
   
3. use non-authenticated role for automation ["N" role flag, along with "s"]
   use "gradm -n role_name" to temporarily activate it without any password, and "gradm -u" to deactivate it. You should use role_transitions to define which roles may use that (you don't want to allow all users to change to role which does not require password!!)

In short, admin role should really never be used for regular system operation (much less automation!), but rather for unprecedented maintenance tasks and changing RBAC policy itself (adding new roles, etc).