[refpolicy] [Patch V2 1/1] Add hwloc-dump-hwdata SELinux policy

[dac.override@gmail.com (Dominick Grift)]

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