From: dominick.grift@gmail.com (grift) Date: Tue, 18 Dec 2012 17:20:01 +0100 Subject: [refpolicy] [PATCH 8/9] Allow capability block_suspend to system_dbusd_t In-Reply-To: <20121218101839.50e371f6@soldur.bigon.be> References: <1355774297-13606-1-git-send-email-bigon@debian.org> <1355774297-13606-8-git-send-email-bigon@debian.org> <1355776703.2269.13.camel@localhost> <20121218093153.68fa5d72@soldur.bigon.be> <1355820277.1849.1.camel@localhost> <20121218101839.50e371f6@soldur.bigon.be> Message-ID: <1355847601.1849.35.camel@localhost> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Tue, 2012-12-18 at 10:18 +0100, Laurent Bigonville wrote: > Le Tue, 18 Dec 2012 09:44:37 +0100, > grift 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