All messages are along: type=AVC msg=audit(1325005143.419:189341): avc: denied { use } for pid=5946 comm="loop0" path="/data/var_amavis.ext4" dev=md7 ino=49156 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:mount_t tclass=fd in enforcing mode these are there a LOT, in non-enforcing mode there might be one. These were caused during restart of fail2ban in enforcing mode in which case 75K of these message were generated in a few seconds. Any loop mounted device seems to generate this kind of errors on use. Reproducible: Always
The rationale for having this on a loop container is that the system has a mirror pair for most data, but spam isn't considered important enough to be stored on a mirror disk. Also the /var filesystem has not enough storage to be able to store it there.
Also i use this for /usr/portage, /usr/src & /usr/share/doc/.
How are the loop filesystems mounted? Do you use mount's "-o loop" or losetup or something equivalent?
They are mounted from fstab, during bootup. ---8<--- /data/var_amavis.ext4 /var/amavis/quarantine-cur ext4 loop,acl,user_xattr,noatime 2 0 /data/usr_portage.ext4 /usr/portage ext4 loop,acl,user_xattr,noatime 2 0 /data/usr_src.ext4 /usr/src ext4 loop,acl,user_xattr,noatime 2 0 /data/usr_share_doc.ext4 /usr/share/doc ext4 loop,acl,user_xattr,noatime 2 0 ---8<--- ( four lines ofcourse, ==> mount -o loop variant is used.)
Ok, you'll need to first mark the image files as something appropriate. You could use var_t but I use virt_image_t. Next either give mount_t (if you use mount directly) or fsadm_t (if you use losetup) the following rights on the image: allow mount_t virt_image_t:file { read write open getattr }; allow kernel_t mount_t:fd { use }; allow kernel_t virt_image_t:file { read write open getattr }; That should suffice to get loop-mounted images done correctly. However, you'll still need to make sure that the mountpoints themselves hold the correct context. I don't mind documenting it, but it's not something that can be added to the policy generically. This is one of the cases where you, as security admin, will need to take the lead imo.
Ok, i'll try that later, I do have another question though, The current setup isn't very update friendly, if someone has private extensions (not too uncommon i hope), it would be nice if they could be added in a guaranteed non-clashing way. /etc/selinux/strict/contexts/files/file_context.manual-update or something like that. So the manual changes survive a reinstall by adding a new profile. Or did I miss something, I tried adding a file there and it's just ignored... And is there a naming rule that prevents colision of private modules with current & possibly future modules.
Don't add files manually, but instead of "semanage fcontext" as per http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=2&chap=2#doc_chap3_sect4 This will keep the changes across updates.
Documentation for adding local changes to the policy is at http://www.gentoo.org/proj/en/hardened/selinux-faq.xml#localpolicy
