[refpolicy] RFC: direct_init_entry breaks direct_initrc

Dominick Grift dominick.grift at gmail.com
Wed Jan 15 10:44:49 EST 2014


On Wed, 2014-01-15 at 08:51 -0500, Christopher J. PeBenito wrote:
> On 01/14/14 17:23, Dominick Grift wrote:
> > On Tue, 2014-01-14 at 15:44 -0500, Christopher J. PeBenito wrote:
> >>
> >> I think you may be able to drop the direct_run_init attribute and put the domtrans you added in the init_run_daemon() interface instead.
> >>
> > 
> > Right, i also got rid of direct_init because was a lose end as well
> > 
> > It builds but still not actually tested
> 
> On further looking it looks like we shouldn't completely remove the direct_sysadm_daemon block out of init_daemon_domain; the userdom_dontaudit_use_user_terminals($1) should probably remain.  I'd also prefer to separate the unconfined portion out to a separate patch.  Otherwise it looks good.
> 

Enclosed patches. Built successfully

By the way this may not be a end-all solution. Since i think commands
like newaliases and rpm *may* also be affected especially with regard to
system_r role but i think that if that turns out to be true that we can
deal with those issue as they arise. (these are some of the very rare
instances where a role transition might also be desired)

In my test on Fedora i did run rpm and did not notice anything except a

allow NetworkManager_t initrc_t:process sigkill;

not sure if that was related but it is kind of weird since Fedora uses
systemd_t so i wasnt expecting anything initrc_t related

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Apply-directinitrc-to-unconfinedrunconfinedt.patch
Type: text/x-patch
Size: 2225 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140115/b910f0c9/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Change-behavior-of-initrundaemon.patch
Type: text/x-patch
Size: 2227 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140115/b910f0c9/attachment-0003.bin 


More information about the refpolicy mailing list