[refpolicy] [PATCH 8/9] Allow capability block_suspend to system_dbusd_t

[dominick.grift@gmail.com (grift)]

On Tue, 2012-12-18 at 10:18 +0100, Laurent Bigonville wrote:
> Le Tue, 18 Dec 2012 09:44:37 +0100,
> grift <dominick.grift@gmail.com> a ?crit :
> 
> > What is "host"
> 
> $ whatis host
> host (1)             - DNS lookup utility
> 
> > can you do a ps auxZ | grep system_dbusd_t
> 
> $ ps auxZ | grep system_dbusd_t
> system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 message+ 3066 0.0  0.0 41632 2560 ? Ssl 09:06   0:01 /usr/bin/dbus-daemon --system
> 
> I'll try to figure out which component is calling this.
> 
> Laurent

Ok , turns out that this was actually due to the mislabeled nm
dispatcher.action program.

Now that it is correctly labeled NetworkManager_initc_exec_t and now
that system_dbusd_t can domain transition to initrc_t via any " init
script file type"  this no longer happens for system_dbusd_t.

Instead we need to allow initrc_t the block suspend capability2

We also tried to label the action program NetworkManager_exec_t but that
caused many other denials and since the same program in a different
location was already also NetworkManager_initrc_exec_t we decided to
stick to that for the sake of uniformity and because we trust that the
decision to label it NetworkManager_initrc_exec_t was well thought out.

By the way, this also made me realize that dbus session domains probably
also should not need block suspend capability.

I ported that rule from Fedora earlier but i have commented it out
( push is pending ) because i would like to reproduce and see the avc
denial