[refpolicy] [PATCH] misc fc changes

[russell@coker.com.au (Russell Coker)]

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.

> > --- 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

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/