grsecurity forums

Hey,

I'm having an lxc - grsec setup (4 lxc containers running on a grsec enabled host system). After being for 2 days in full learn mode I've tried to generate the policy for gradm.
This was successfull, however when I checked the policy with gradm -C, gradm spits out several errors:

Duplicate subject found for "/usr/bin/lockfile-remove" in role root, on line 751 of /etc/grsec/policy.
"/usr/bin/lockfile-remove" references the same object as "/usr/bin/lockfile-create" specified on an earlier line.
The RBAC system will not load until this error is fixed.

In order to fix this error I removed the subject entries for lockfile-remote and lockfile-touch which spits out just the same error.

Afterwards I get the notification that /dev/ is not hidden for the user "man", after fixing this gradm -C doesn yell around anymore.

But after loading the policy with gradm -E dmesg outputs a LOT of denied access to quite common files, which are (in my eyes) readable according to the policy:
All system services (httpd, smtpd, ejabberd, imapd, etc.) stop to work immidately, ssh is running without problems.

Is this kind of behaviour normal for RBAC? I supposed the full learning mode to generate a working copy so that the daemons which were running during the learning phase can run without problems when the policy is activated. If anybody has a clue what is going on here, it would be nice to get a hint.

Thanks in advance

ps: I can of course provide the complete policy and learning.log file if necessary

Here are some of the dmesg entries, just for reference:
[279227.044125] grsec: From 134.61.86.234: (root:U:/sbin/klogd) denied access to hidden file /etc/localtime by /sbin/klogd[klogd:2990] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1728] uid/euid:0/0 gid/egid:0/0
[278976.869691] grsec: From 134.61.86.234: (root:U:/usr/sbin/cron) denied access to hidden file /etc/crontab by /usr/sbin/cron[cron:2901] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1728] uid/euid:0/0 gid/egid:0/0
[278976.869393] grsec: From 134.61.86.234: (root:U:/usr/sbin/cron) denied access to hidden file /var/spool/cron/crontabs by /usr/sbin/cron[cron:2901] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1728] uid/euid:0/0 gid/egid:0/0
[278975.968128] grsec: From 85.197.21.96: (root:U:/usr/lib/postfix/master) denied access to hidden file /var/spool/postfix/public/pickup by /usr/lib/postfix/master[master:10792] uid/euid:0/102 gid/egid:0/104, parent /sbin/init[init:1887] uid/euid:0/0 gid/egid:0/0
[278963.969907] grsec: From 85.197.21.96: (root:U:/usr/lib/postfix/master) denied access to hidden file /usr/lib/postfix/smtpd by /usr/lib/postfix/master[master:11050] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/postfix/master[master:10792] uid/euid:0/0 gid/egid:0/0
[278661.498623] grsec: From 85.197.21.96: (Debian-exim:U:/usr/lib/dovecot/imap-login) denied access to hidden file /var/run/dovecot/login/ssl-parameters.dat by /usr/lib/dovecot/imap-login[imap-login:26569] uid/euid:103/103 gid/egid:106/106, parent /usr/sbin/dovecot[dovecot:3795] uid/euid:0/0 gid/egid:0/0
[278671.779532] grsec: From 134.61.86.234: (root:U:/sbin/syslogd) denied access to hidden file /etc/localtime by /sbin/syslogd[syslogd:2818] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1728] uid/euid:0/0 gid/egid:0/0

I've found at least partly the solution:

all the uids/gids which are used in the containers needs to be also present in the main host, as gradm doesn't generate role names using uids. user_transition_allow/deny accepts uids.
if gradm doesn't find the user in the host it put the subject into the root role, which doesn't work of course (it would be better to put it maybe into the default role instead to ensure that the system can work).

However still the daemons doesn't work properly in many cases and I doesn't find the error. As the policy file is quite long (>4000 lines) I won't paste it here, but send it by request by email.

e.g.:
[286836.151714] grsec: From 85.197.21.96: (Debian-exim:U:/usr/lib/dovecot/imap-login) denied access to hidden file /var/run/dovecot/login/ssl-parameters.dat by /usr/lib/dovecot/imap-login[imap-login:14801] uid/euid:103/103 gid/egid:106/106, parent /usr/sbin/dovecot[dovecot:3795] uid/euid:0/0 gid/egid:0/0

but I've in my policy the following rule:
role Debian-exim u
subject / {
/ h
/var/run/dovecot r
/var/run/dovecot/* r
-CAP_ALL
bind disabled
connect disabled
}

subject /usr/lib/dovecot/imap-login o {
/ h
/var/run/dovecot/login
/var/run/dovecot/login/default rw
/var/run/dovecot/login/ssl-parameters.dat r
/var/lib/dovecot/ssl-parameters.dat r
-CAP_ALL
bind 0.0.0.0/0:993 stream tcp
connect disabled
sock_allow_family netlink
}


with:
ks354798:/etc/grsec# getent passwd 103
Debian-exim:x:103:106::/var/spool/exim4:/bin/false

so, the service is running as uid 103, and according to the policy has read access to the ssl-parameters.dat file... which is hidden according to the dmesg output. Any ideas?

The policy can be seen here. I've already started to modify it but I've not manage to run any system service correctly.

http://www.der-winnie.de/policy - note I've removed the policy there after spencer's answer.

I should have been more clear in my email I guess I said that RBAC "won't play nicely with containers" by which I meant that it won't work if there are containers in use. You're seeing part of the problem I mentioned: you're having pathnames logged relative to the root of a certain container, yet the path suggests that it exists on the real filesystem outside of the container. When you load the policy with gradm -E, it doesn't know anything about any of the containers (since all the paths are relative to the container roots) and so it associates the filenames with the inode/device pairs of the files as they exist on the main filesystem tree (if they exist there at all). So then this of course doesn't match when the container accesses occur, and you get the error messages that don't make sense.

Like I mentioned via email, I'm trying to work on a way to support containers, but there are only so many hours in a day.

-Brad

Ah okay... then I completley missunderstood you in this point. I thought that you mean with "won't play nicely" that RBAC doesn't see that a process is running in a container, but will allow the access if it happens.

thanks anyway for your help!