(2.3 userspace!) When installing postfix to replace nullmailer (no selinux policy, no interest in writing one) under enforcing, I find that portage has some issues relabeling stuff in etc_t: Nov 18 06:44:10 testbed kernel: [128276.205110] audit: type=1400 audit(1416314650.276:637): avc: denied { relabelfrom } for pid=32128 comm="install" name="server.key" dev="dm-3" ino=429201 ipaddr=173.173.113.156 scontext=root:sysadm_r:portage_t tcontext=root:object_r:etc_t tclass=file permissive=0 Nov 18 06:44:10 testbed kernel: [128276.216437] audit: type=1400 audit(1416314650.288:638): avc: denied { relabelfrom } for pid=32132 comm="install" name="server.csr" dev="dm-3" ino=429202 ipaddr=173.173.113.156 scontext=root:sysadm_r:portage_t tcontext=root:object_r:etc_t tclass=file permissive=0 Nov 18 06:44:10 testbed kernel: [128276.227910] audit: type=1400 audit(1416314650.299:639): avc: denied { relabelfrom } for pid=32134 comm="install" name="server.crt" dev="dm-3" ino=429203 ipaddr=173.173.113.156 scontext=root:sysadm_r:portage_t tcontext=root:object_r:etc_t tclass=file permissive=0 Nov 18 06:44:10 testbed kernel: [128276.239960] audit: type=1400 audit(1416314650.311:640): avc: denied { relabelfrom } for pid=32136 comm="install" name="server.pem" dev="dm-3" ino=429205 ipaddr=173.173.113.156 scontext=root:sysadm_r:portage_t tcontext=root:object_r:etc_t tclass=file permissive=0 Nov 18 06:53:35 testbed kernel: [128841.672960] audit: type=1400 audit(1416315215.296:645): avc: denied { relabelfrom } for pid=6919 comm="install" name="server.key" dev="dm-3" ino=428419 ipaddr=173.173.113.156 scontext=root:sysadm_r:portage_t tcontext=root:object_r:etc_t tclass=file permissive=1 Nov 18 06:53:35 testbed kernel: [128841.672981] audit: type=1400 audit(1416315215.296:646): avc: denied { relabelto } for pid=6919 comm="install" name="server.key" dev="dm-3" ino=428419 ipaddr=173.173.113.156 scontext=root:sysadm_r:portage_t tcontext=system_u:object_r:etc_t tclass=file permissive=1 The last line was under permissive to see what else it wanted. When you install postfix, it wants to generate a set of ssl keys for TLS mail. This is what you get under enforcing under current policy: # ls -althrZ /etc/ssl/postfix total 24K drwxr-xr-x. 8 root root system_u:object_r:etc_t 4.0K Nov 18 06:44 .. -r--------. 1 postfix mail root:object_r:etc_t 887 Nov 18 06:44 server.key -r--r--r--. 1 root root root:object_r:etc_t 749 Nov 18 06:44 server.csr -r--r--r--. 1 root root root:object_r:etc_t 1.1K Nov 18 06:44 server.crt -r--------. 1 postfix mail root:object_r:etc_t 1.9K Nov 18 06:44 server.pem drwxr-xr-x. 2 root root root:object_r:etc_t 4.0K Nov 18 06:44 . This is what it wants, when you let it: # ls -althrZ /etc/ssl/postfix total 24K drwxr-xr-x. 8 root root system_u:object_r:etc_t 4.0K Nov 18 06:53 .. -r--------. 1 postfix mail system_u:object_r:etc_t 891 Nov 18 06:53 server.key -r--r--r--. 1 root root system_u:object_r:etc_t 749 Nov 18 06:53 server.csr -r--r--r--. 1 root root system_u:object_r:etc_t 1.1K Nov 18 06:53 server.crt -r--------. 1 postfix mail system_u:object_r:etc_t 1.9K Nov 18 06:53 server.pem drwxr-xr-x. 2 root root root:object_r:etc_t 4.0K Nov 18 06:53 . Fixing this for etc_t is easy: files_relabel_etc_files(portage_t) But since portage has to manage all files, why not this? Allowing portage to relabel everything (I thought it could, its portage!) solves this issue for this and every case and I can't easily conjur an argument why the portage_t domain shouldn't have this power. Patch: diff --git a/policy/modules/contrib/portage.te b/policy/modules/contrib/portage.te index 83d6ab4..744ddb5 100644 --- a/policy/modules/contrib/portage.te +++ b/policy/modules/contrib/portage.te @@ -195,6 +195,7 @@ domain_dontaudit_read_all_domains_state(portage_t) # modify any files in the system files_manage_all_files(portage_t) +files_relabel_all_files(portage_t) selinux_get_fs_mount(portage_t)
Correction: Definitely use files_relabel_etc_files(portage_t) auth_relabelto_shadow() has to be called explicitly because files_relabel_all_files means shadow_t can be relabeled, and shadow_t doesn't want that unless you explicitly let it. Maaayybee I should leave that alone and stick to files_relabel_etc_files().
Err, normally portage relabels files post-install (using a domain transition to setfiles). I'm going to see if I can reproduce this, but granting portage with relabel permissions should not be the goal afaics.
Okay, well, apparently postfix' pkg_postinst inserts the files. However, although we do get the error about portage' unability to manage the files, I'd like to keep it this way for now. portage_t itself has few relabel privileges and this would just start expanding it. Considering that the files do get etc_t (according to the policy, this is correct, even though I think it would be wiser to mark them as certificates or keys), I'll have this block a policy rewrite for portage.
