From: dac.override@gmail.com (Dominick Grift) Date: Wed, 27 Apr 2016 20:30:30 +0200 Subject: [refpolicy] [Patch V2 1/1] Add hwloc-dump-hwdata SELinux policy In-Reply-To: <57210055.2010808@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> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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() Anyhow it is just a matter of taste, and i accept this decision and i will try to remember this in the future. (it will be kind of confusing but i will try) - -- 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 iQGcBAEBCAAGBQJXIQVBAAoJECV0jlU3+UdpQxQL+gM0zuRtOzeqxgrzzoVuMC9Y 43Fuc3TTPE4ryXjPlPZg8pZB+LfuTTwOvxg27h+ngQjgz9ozWUdHEo9vqdAMsgJE QKpuCF6pWAwvMvUHFCBxkPVs5U92MTBvjGNeWFw22PbS84UZOkm+PiJgGEwK/99d anTZMU6NGyORJNGAgPfjww6TWOgpKpRa+QvRRnA0joOGhO2EkOLTcWQ5WSkPyl4h qAq5TbmbIQSKJvsuBSsOjS0tYxv1YFi3Mx8GfX3ZARVZ9bJn8DNOrq75PD4h3X+I YciK1gSGpQ7E8IWBvPzpWvH1VnRKQw8PayZuwjkRxAhWkZtAHZPlDXRpXRt5KWG2 0ODn/Azc/hZB4MrNZQz5eTPZt8LldfOCG4U80iEHJfedjNreDWEzxFUD76+SzNC1 Wt3POeJHcP7nuK34ywomRTHQGLRDSXugLo5XRnZ/jY/5wyWGN6ytFpaat3Xu41ep udLI9GxRcdXokHRGwwiK5s54s8lRMeMJRMLYeve8gA== =7Yf1 -----END PGP SIGNATURE-----