From: dac.override@gmail.com (Dominick Grift) Date: Tue, 4 Apr 2017 10:08:03 +0200 Subject: [refpolicy] [PATCH] misc fc changes In-Reply-To: <201704041800.33260.russell@coker.com.au> References: <20170402085805.2zlddx2evzcgxgop@athena.coker.com.au> <20170404074424.GC10685@t450.enp8s0.d30> <201704041800.33260.russell@coker.com.au> Message-ID: <20170404080803.GF10685@t450.enp8s0.d30> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Tue, Apr 04, 2017 at 06:00:33PM +1000, Russell Coker wrote: > On Tue, 4 Apr 2017 05:44:24 PM Dominick Grift via refpolicy wrote: > > On Sun, Apr 02, 2017 at 06:58:05PM +1000, Russell Coker via refpolicy wrote: > > > Remove acct_exec_t label for /etc/cron\.(daily|monthly)/acct so it gets > > > bin_t > > > > > > Label /dev/pts/ptmx as ptmx_t. It always should have been labelled like > > > this but the presence of a device /dev/ptmx concealed it. With a > > > container created by systemd-nspawn (and possibly other situations) > > > /dev/ptmx is a symlink and we need correct labelling of /dev/pts/ptmx. > > > > > > Remove labelling of /usr/sbin/apachectl as initrc_exec_t so system > > > scripts can run it without a domain transition. > > > > > > Also lots of little changes that are obvious. > > > > > > > > > --- refpolicy-2.20170329.orig/policy/modules/contrib/acct.fc > > > +++ refpolicy-2.20170329/policy/modules/contrib/acct.fc > > > @@ -1,5 +1,3 @@ > > > -/etc/cron\.(daily|monthly)/acct -- > gen_context(system_u:object_r:acct_ex > > > ec_t,s0) - > > > > Any specific reason for removing this? system_cronjob_t is pretty broad, so > > i tend to move stuff out of there whenever that makes a little sense > > Those scripts use systemctl to restart daemons. The choice is between having > system_cronjob_t run some scripts that are in almost all cases unaltered from > the distribution or allowing acct_t to restart daemons. Ok yes that sounds like an compelling argument. > > > > --- refpolicy-2.20170329.orig/policy/modules/system/libraries.fc > > > +++ refpolicy-2.20170329/policy/modules/system/libraries.fc > > > @@ -105,6 +105,7 @@ ifdef(`distro_debian',` > > > > > > /usr/(.*/)?dh-python/dh_pypy -- > gen_context(system_u:object_r:lib_t,s0) > > > ') > > > > > > +/usr/lib/postfix/lib.*so.* -- > gen_context(system_u:object_r:lib_t,s0) > > > > That looks like it might be redundant or that there is some other spec that > > should probably ideally be more specific for this location > > # restorecon -R -v /usr/lib/postfix/ > Relabeled /usr/lib/postfix/libpostfix-dns.so from system_u:object_r:lib_t:s0 to > system_u:object_r:postfix_exec_t:s0 > Relabeled /usr/lib/postfix/libpostfix-global.so from system_u:object_r:lib_t:s0 > to system_u:object_r:postfix_exec_t:s0 > Relabeled /usr/lib/postfix/libpostfix-master.so from system_u:object_r:lib_t:s0 > to system_u:object_r:postfix_exec_t:s0 > Relabeled /usr/lib/postfix/libpostfix-tls.so from system_u:object_r:lib_t:s0 to > system_u:object_r:postfix_exec_t:s0 > Relabeled /usr/lib/postfix/libpostfix-util.so from system_u:object_r:lib_t:s0 to > system_u:object_r:postfix_exec_t:s0 Then maybe that postfix_exec_t context spec could be more specific to not include libraries? if like of strange to have a lib_t base type for /usr/lib and to then have to specify lib_t for some individual lib file > > No, if that line is removed then we get the wrong context. > > > > --- refpolicy-2.20170329.orig/policy/modules/system/lvm.fc > > > +++ refpolicy-2.20170329/policy/modules/system/lvm.fc > > > @@ -42,6 +42,7 @@ ifdef(`distro_gentoo',` > > > > > > /usr/sbin/lvdisplay -- > gen_context(system_u:object_r:lvm_exec_t,s0) > > > /usr/sbin/lvextend -- > gen_context(system_u:object_r:lvm_exec_t,s0) > > > /usr/sbin/lvm -- > gen_context(system_u:object_r:lvm_exec_t,s0) > > > > > > +/usr/sbin/lvmetad -- > gen_context(system_u:object_r:lvm_exec_t,s0) > > > > Fedora does this as well and i am wonder whether this is a good idea in the > > longer run > > It's probably something I copied from Fedora. ;) > > > lvm is short running, lvmetad is long running > > lvm probably needs permission to raw storage? it remains to be seen whether > > this daemon needs access to raw storage as well (if it doesnt then that to > > me is reason enough to move it out of lvm_t) > > OK, well if you would like to contribute policy for lvmetad_t then that would > be great. In the mean time I think this is the best option. > > > > --- refpolicy-2.20170329.orig/policy/modules/system/miscfiles.fc > > > +++ refpolicy-2.20170329/policy/modules/system/miscfiles.fc > > > @@ -12,7 +12,7 @@ ifdef(`distro_gentoo',` > > > > > > /etc/httpd/alias/[^/]*\.db(\.[^/]*)* -- > > > gen_context(system_u:object_r:cert_t,s0) > > > /etc/localtime -- gen_context(system_u:object_r:locale_t,s0) > > > /etc/pki(/.*)? gen_context(system_u:object_r:cert_t,s0) > > > > > > -/etc/ssl(/.*)? gen_context(system_u:object_r:cert_t,s0) > > > +/etc/ssl/private(/.*)? > gen_context(system_u:object_r:cert_t,s0) > > > > There probably should not be private keys on a production system in the > > first place? Regardless, atleast be consistent and apply this to /etc/pki > > as well > > My systems don't have a /etc/pki directory. It would be good if someone who > has such a system could contribute a patch for it, maybe you? > > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Blog http://doc.coker.com.au/ -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170404/057f8d83/attachment.bin