(Again, this is running on current policy git) It looks like the default init permissions aren't quite sufficiently expansive for openrc. When I tell openrc to re/start a service: Nov 15 07:14:18 testbed kernel: [170505.139991] audit: type=1400 audit(1416057258.057:4598): avc: denied { search } for pid=8508 comm="openrc" name="1" dev="proc" ino=5499 ipaddr=173.173.113.156 scontext=root:sysadm_r:run_init_t tcontext=system_u:system_r:init_t tclass=dir permissive=1 Nov 15 07:14:18 testbed kernel: [170505.140039] audit: type=1400 audit(1416057258.057:4599): avc: denied { read } for pid=8508 comm="openrc" name="environ" dev="proc" ino=1404 ipaddr=173.173.113.156 scontext=root:sysadm_r:run_init_t tcontext=system_u:system_r:init_t tclass=file permissive=1 Nov 15 07:14:18 testbed kernel: [170505.140096] audit: type=1400 audit(1416057258.057:4600): avc: denied { open } for pid=8508 comm="openrc" path="/proc/1/environ" dev="proc" ino=1404 ipaddr=173.173.113.156 scontext=root:sysadm_r:run_init_t tcontext=system_u:system_r:init_t tclass=file permissive=1 Nov 15 07:14:18 testbed kernel: [170505.140143] audit: type=1400 audit(1416057258.057:4601): avc: denied { getattr } for pid=8508 comm="openrc" path="/proc/1/environ" dev="proc" ino=1404 ipaddr=173.173.113.156 scontext=root:sysadm_r:run_init_t tcontext=system_u:system_r:init_t tclass=file permissive=1 Nov 15 07:14:18 testbed kernel: [170505.140395] audit: type=1400 audit(1416057258.057:4602): avc: denied { read } for pid=8508 comm="openrc" name="softlevel" dev="tmpfs" ino=2113 ipaddr=173.173.113.156 scontext=root:sysadm_r:run_init_t tcontext=system_u:object_r:initrc_state_t tclass=file permissive=1 Nov 15 07:14:18 testbed kernel: [170505.140415] audit: type=1400 audit(1416057258.057:4603): avc: denied { open } for pid=8508 comm="openrc" path="/run/openrc/softlevel" dev="tmpfs" ino=2113 ipaddr=173.173.113.156 scontext=root:sysadm_r:run_init_t tcontext=system_u:object_r:initrc_state_t tclass=file permissive=1 Nov 15 07:14:18 testbed kernel: [170505.140436] audit: type=1400 audit(1416057258.057:4604): avc: denied { getattr } for pid=8508 comm="openrc" path="/run/openrc/softlevel" dev="tmpfs" ino=2113 ipaddr=173.173.113.156 scontext=root:sysadm_r:run_init_t tcontext=system_u:object_r:initrc_state_t tclass=file permissive=1 Nov 15 07:14:19 testbed kernel: [170506.329548] audit: type=1400 audit(1416057259.245:4605): avc: denied { dac_override } for pid=8710 comm="rmdir" capability=1 scontext=system_u:system_r:openrc_cgroup_release_t tcontext=system_u:system_r:openrc_cgroup_release_t tclass=capability permissive=1 Nov 15 07:14:19 testbed kernel: [170506.383565] audit: type=1400 audit(1416057259.299:4606): avc: denied { dac_override } for pid=8723 comm="rmdir" capability=1 scontext=system_u:system_r:openrc_cgroup_release_t tcontext=system_u:system_r:openrc_cgroup_release_t tclass=capability permissive=1 The openrc module is a little screwy in my estimate, but I guess that's what happens when you have to play well with others (systemd, sysvinit). There are two issues here: 1) openrc wants to grab stuff from init's environment via /proc - reasonable! 2) openrc wants dac_override. I'm not 100% sure why - privilege dropping perhaps? This process is seriously challenging my grasp of how Linux really works. #2 is a one line fix. #1 is twice as hard to fix. Fortunately init has the proper interfaces to transition a domain such that it can read states and such.
Created attachment 389404 [details, diff] openrc now cooperates better
which version of openrc are you running? I fixed a lot of selinux issues in the 0.13 series of openrc. Can you try the latest one and see if it makes a difference? dac_override is the wrong solution. It has to do with the perms on the cgroup dir.
Also, check if the requested permissions are needed or not. Run in enforcing mode and write down the errors that you get (alongside the avc denials) so we know which ones are needed. Many AVC denials are cosmetic and should just be dontaudit'ed, or confined by the authors that they are needed in specific situations.
Jason: Yeah, I was wondering about dac_override. Its' utility is a bit fuzzy for me as I am not 100% sure if my understanding of it is correct. I am running out of ~arch, so it is openrc 0.13.4 with the following use flags: "ncurses netifrc pam selinux unicode" Sven: I understand that some avc policy denials are nuisance, but it is my time to waste (well, until Sven has to integrate). The problem is that I don't have an easy way of seeing how "necessary" a denial is. This bug, for example, comes up WHENEVER I do service management. Especially on startup/shutdown. Personally I am treating this the same way I treat firewall rules. I want everything to work 100% with no bitching, even if some of it is cosmetic. That is why I am not digging super deep into whether a requirement is absolutely necessary. The program wants the access, and unless the reson is dangerous, a misconfiguration, or one of my stupid edge cases, I'm going to try to set the policy accordingly. You won't be seeing much in the way of dontaudit directives out of me, as that basically says "this is a problem. let's ignore it." and codifies it as policy. The distant problem you have to consider is someone running this in enforcing and they see a log entry. The admin has to take the time to consider whether this is just bullshit noise, or an actual issue. Rinse and repeat for every package that has cosmetic denials. For example, the hardware I have running this policy on is what one would absolutely call a "hostile" environment. There's a need. Consider this an investment in the signal to noise ratio. So leaving the init_t transitions and focusing on the dac_override issue. Putting the system into enforcing mode (now that I have a nearly-there policy) and stracing through (after enabling the ptrace boolean) shows me the following when I try to restart named: [pid 28604] rmdir("/run/openrc/daemons/named" <unfinished ...> This is the only time it happens, and that's when it is going through its' checking of the named state. Which presumably includes regenerating the state file. While it might not be useful for this audience, Dan Walsh wrote up something useful for the dac_ovveride discussion: https://danwalsh.livejournal.com/69478.html Going through the stop / start / stop cycle in enforcing, I see the rmdir() call is in fact working just fine. The directory tree is already root:root and doesn't actually need dac_override - its' like root sudo'ing to root. So I'm gonna go ahead and say this is an openrc silliness, and that you were right about dontaudit on this. Of course I now see named wanting to read sysctls and being told "no" but that's for another bug. So: -allow openrc_cgroup_release_t self:capability dac_override; +dontaudit openrc_cgroup_release_t self:capability dac_override; Works.
dac_override means that the DAC permissions are wrong on something so the program is doing it anyway (since it is root). The solution to this is almost never to actually give dac_override and instead fix the permission issue. So i just checked through openrc's source and looks like I had not upstreamed the fix. Can you paste the output of "ls -alZ /sys/fs/cgroup/" as well as "mount" before doing anything below. The fix is to find add "mode=755" to the mount command in /etc/init.d/sysfs so that it is given write access.
# ls -alZ /sys/fs/cgroup/ total 0 drwxr-xr-x. 7 root root system_u:object_r:cgroup_t 140 Nov 15 08:10 . drwxr-xr-x. 5 root root system_u:object_r:sysfs_t 0 Nov 15 08:10 .. dr-xr-xr-x. 2 root root system_u:object_r:cgroup_t 0 Nov 15 08:10 cpu dr-xr-xr-x. 2 root root system_u:object_r:cgroup_t 0 Nov 15 08:10 cpuacct dr-xr-xr-x. 2 root root system_u:object_r:cgroup_t 0 Nov 15 08:10 cpuset dr-xr-xr-x. 2 root root system_u:object_r:cgroup_t 0 Nov 15 08:10 net_cls dr-xr-xr-x. 17 root root system_u:object_r:cgroup_t 0 Nov 15 08:10 openrc # mount proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,seclabel,size=10240k,nr_inodes=1022010,mode=755) devpts on /dev/pts type devpts (rw,relatime,seclabel,gid=5,mode=620) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel) /dev/mapper/root on / type ext4 (rw,noatime,seclabel,data=ordered) selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,rootcontext=system_u:object_r:var_run_t,seclabel,mode=755) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime,seclabel) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime) cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,size=10240k,mode=755) openrc on /sys/fs/cgroup/openrc type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc) cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cpu on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu) cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct) net_cls on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) /dev/sda1 on /boot type ext4 (rw,noatime,seclabel,data=ordered) /dev/mapper/crypt-bitcoin on /var/lib/bitcoin type ext4 (rw,noatime,seclabel,data=ordered) tmpfs on /tmp type tmpfs (rw,nosuid,noexec,relatime,rootcontext=system_u:object_r:tmp_t,seclabel) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) From /etc/fstab: tmpfs /run tmpfs mode=0755,nosuid,nodev,rootcontext=system_u:object_r:var_run_t 0 0 tmpfs /tmp tmpfs defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t 0 0 The funny thing is that it already has write access. # stat /run/openrc/daemons/named File: '/run/openrc/daemons/named' Size: 60 Blocks: 0 IO Block: 4096 directory Device: 11h/17d Inode: 12374346 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:initrc_state_t Access: 2014-11-15 18:22:21.856734625 -0600 Modify: 2014-11-15 17:59:37.498396282 -0600 Change: 2014-11-15 17:59:37.498396282 -0600 Birth: - Eg, what /run has above in fstab (the documentation-suggested configuration). Once I took the time to strace through this and see what it was doing and walk through step by step, the only actual issue was that openrc simply wanted MORE access. Just in case, or something. Nothing was actually failing so I went sven's route of dontaudit on the dac_override request. Seems to be fine. I won't be satisfied until I can do a few shutdown / startup cycles with it in place though, which I haven't done quite yet.
(In reply to Eric Gisse from comment #6) > # ls -alZ /sys/fs/cgroup/ This is the problematic line, it is missing write access: > dr-xr-xr-x. 17 root root system_u:object_r:cgroup_t 0 Nov 15 08:10 openrc > > # mount > openrc on /sys/fs/cgroup/openrc type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release- agent.sh,name=openrc) mode=755 needs to be added here ^^ > > The funny thing is that it already has write access. > # stat /run/openrc/daemons/named I should have been clearer, the issue is the permissions on /sys/fs/cgroup/openrc/ not on /run/openrc. > Nothing was actually failing so I went sven's route of dontaudit on the > dac_override request. Seems to be fine. I won't be satisfied until I can do > a few shutdown / startup cycles with it in place though, which I haven't > done quite yet. all that is happening is that some dirs are left around (inside /sys/fs/cgroup/openrc) which isnt actually harmful but i found it annoying. If you edit /etc/init.d/sysfs and look for the mount_cgroups() function where it mounts /sys/fs/cgroup/openrc, you need to add mode=755 before name=openrc. diff --git a/init.d/sysfs.in b/init.d/sysfs.in index 67485c2..d9155a3 100644 --- a/init.d/sysfs.in +++ b/init.d/sysfs.in @@ -105,7 +105,7 @@ mount_cgroups() local agent="@LIBEXECDIR@/sh/cgroup-release-agent.sh" mkdir /sys/fs/cgroup/openrc mount -n -t cgroup \ - -o none,${sysfs_opts},name=openrc,release_agent="$agent" \ + -o none,${sysfs_opts},mode=755,name=openrc,release_agent="$agent" \ openrc /sys/fs/cgroup/openrc echo 1 > /sys/fs/cgroup/openrc/notify_on_release fi Also make sure you remove your dontaudits before you edit this otherwise you wont know if its working. If this fix works for you, i'll get it added to the next version of OpenRC. -- Jason
(In reply to Jason Zaman from comment #7) > Also make sure you remove your dontaudits before you edit this otherwise you > wont know if its working. > If this fix works for you, i'll get it added to the next version of OpenRC. > > -- Jason It worked in that the directory changed its' permission. Definitely push the fix as its' a good idea to have the right perms on these things. However, it did not work in that the complaint continues (I disabled dontaudit). However, that does not actually cause any problems for me in full enforcing mode so I am going to stick with the dontaudit plan and call it noise. I'm still tinkering with things relating to the init space, as I have a small pile of denials on startup/shutdown to deal with. So my thoughts might change but that's how it looks for now.
