From: dac.override@gmail.com (Dominick Grift) Date: Wed, 27 Apr 2016 20:44:55 +0200 Subject: [refpolicy] [Patch V2 1/1] Add hwloc-dump-hwdata SELinux policy In-Reply-To: <57210746.9030201@tresys.com> References: <1461745535-6857-1-git-send-email-grzegorz.andrejczuk@intel.com> <1461770515-13153-1-git-send-email-grzegorz.andrejczuk@intel.com> <1461770515-13153-2-git-send-email-grzegorz.andrejczuk@intel.com> <5720F7FE.80603@tresys.com> <78d8575f-2650-81c7-1be1-176108885041@gmail.com> <57210055.2010808@tresys.com> <57210746.9030201@tresys.com> Message-ID: <5fa376db-5df1-e18e-0055-47b0723a7dcb@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/27/2016 08:39 PM, Christopher J. PeBenito wrote: > On 4/27/2016 2:30 PM, Dominick Grift wrote: >> On 04/27/2016 08:09 PM, Christopher J. PeBenito wrote: >> >>>> >>>> So yes this is definitely a matter of taste. I like to keep >>>> some room to manouver and this this is a reasonable >>>> compromise. >> >>> I understand the desire to be flexible, but this doesn't give >>> us the chance to be more restrictive. >> >>> Ultimately I'm not persuaded simply because sysadm can already >>> manage all these files. I'd like to reduce sysadm's access, but >>> I think the blanket pid access makes sense. Splitting into two >>> or three interfaces is more flexible from the policy writing >>> perspective, and the flexible (from the runtime perspective) >>> behavior you describe above is what is desired, then all of >>> the interfaces can be called. Then we still have room for >>> more restrictive cases. >> >> >> So now that i have accepted your point of view let me explain why >> I do not do this with DSSP >> >> I do not give blanket access to sysadm to maintain all of >> /var/run, this is part of my ".adm()" implementation. >> >> managing services can be done on an individual level in DSSP so >> hwloc.adm() can manage /var/run/hwloc (and when i mean "manage" >> i mean rm -rf /var/run/hwloc && mkdir -Z /var/run/hwlok) but not >> /var/run/http >> >> sysadm is (almost) merely the accumulation of all the ".adm()" >> macros available. So if i would give sysadm blacket /var/run >> access then that would just be duplicate because sysadm can >> already manage it via the ".adm()" macro calls. >> >> I think though that your approach explained above seems a little >> inconsistent with your desire to not give login users "blanket" >> access to user content via for example: >> userdom_manage_all_home_content() userdom_relabel_home_content() >> >> In that instance you do want to give access on individual basis >> example: firefox.manage_home_content() >> firefox.relabe_home_content() > > This is a good point; I would prefer that sysadm also be a > collection calls to admin() interfaces too, and it has slowly been > moving that way. Hopefully we we will be able to eliminate the > blanket access some time in the future. However, the interface > we're talking about is not the hwloc_admin() interface. I would be > fine changing this interface into the hwloc_admin() interface. > Indeed. A hwloc_admin() should have been created and called instead. But I still stay of the opinion that "manage_runtime" should mean that all of it can be managed as opposed to only specified content under the top-level. - -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJXIQihAAoJECV0jlU3+Udp3P8L/Rq22uk9t0t1JOtVqvBtrp22 bl/JH2+jAelycJnq1NONJj6vPYBa+ySWh43nvwD5OHDOOUhU7oAPMWciyLJhMPHh zvE0BvGizj/J09W6RD3GTHGjFV0+54bZxWIfmTO9L6Rb/GvX8EEl8mTloAvsNZjs hqlGdE/xX/Jpj+HJ1ghfn9+qnRpVh7Pb04eTBvB9Xe0ekT0cfCb1PNt/ULzPr1Gm 11cHCNZV3tBqWllwFTdVaOmmyICJcxfSr85UlIbgqCb8wIID/Z7BlgCS+IBe3/x/ hw5cmzBVEVZCDZDzxIM82eOEDuctG9lFkUrmGYuq0JRQQ9+oSoHmT8pp81IPY2B3 aNSyzYtzSQBNMwhDUo2h6jH7f+5OdnN0uVnhJUpLSMPpv3QUa0BRqYsVnpuBTq6O bXPoZ615UBSMra26AHyByn7EFYGxWzN4w15OjzhCs0xurb4ZNaUTCqejPPCefGt0 7cyjHEgGjoiiHsBj42cOPRtO9O1vuwkkcd/UJ8u24w== =0K5A -----END PGP SIGNATURE-----