As per tradition, I have a hard time giving useful titles to LVM problems because they are always hard to put into words. Creating a new logical volume results in a series of small denials: # lvcreate -n squid -L+500G server --zero n WARNING: "server/squid" not zeroed Logical volume "squid" created (The --zero n is silly. it is a workaround for #530602) Denials: Jan 8 01:37:29 testbed kernel: [28549.831785] audit: type=1400 audit(1420702649.386:1263): avc: denied { setattr } for pid=47 comm="kdevtmpfs" name="dm-6" dev="devtmpfs" ino=10993394 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:device_t tclass=blk_file permissive=1 Jan 8 01:37:29 testbed kernel: [28549.837071] audit: type=1400 audit(1420702649.391:1264): avc: denied { search } for pid=10336 comm="lvcreate" name="/" dev="tmpfs" ino=5425 ipaddr=173.173.113.156 scontext=root:sysadm_r:lvm_t tcontext=system_u:object_r:cgroup_t tclass=dir permissive=1 Jan 8 01:37:50 testbed kernel: [28571.337423] audit: type=1400 audit(1420702670.875:1265): avc: denied { setattr } for pid=47 comm="kdevtmpfs" name="dm-6" dev="devtmpfs" ino=11005444 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:device_t tclass=blk_file permissive=1 The interface fs_search_cgroup_dirs() for the cgroup_t denial seems innocuous enough. But dev_setattr_generic_dirs() for device_t is pretty big, though it would solve the issue. Not sure if that's optimal, but would solve the issue. On my previous LVM pass I was entirely focused on userspace daemons running properly and didn't consider lv/pv/vg creation. I squish and report as I find them.
The cgroup search privs is moved to its own bug (bug #542110) The kdevtmpfs aspects are probably cosmetic right now, but kdevtmpfs is made to manage /dev so we should honour this assignment through the policy.
I added in dev_manage_all_dev_nodes(kernel_t) to the policy. Is in repo, will be in rev 4.
Damn, dev_manage_all_dev_nodes can't be used as it depends on an attribute set by the storage module, whereas kernel_t is part of the base (and as such cannot depend on modules). Working on it...
Upstream discussion: http://oss.tresys.com/pipermail/refpolicy/2015-March/007564.html Gentoo hardened discussion also initiated (as one of the difficulties lays with the 2.3 <-> 2.4 situation that we currently are at).
Hardened ml discussion: http://thread.gmane.org/gmane.linux.gentoo.hardened/6411 Looks like we will probably wait before implementing this. In the mean time, you can manually add the rule (as a separate module) as that does not have the side-effect that directly editing kernel.te has.
I'm going to mark this as UPSTREAM. As long as CIL isn't the master for the policies, we probably can't do much, and I don't see refpolicy adding more stuff to the base module just to get this going.
