Re: let's revert e3cab998b48ab293a9962faf9779d70ca339c65d

[Dominick Grift <dac.override@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

On Fri, Apr 14, 2017 at 11:33:25AM -0400, Stephen Smalley wrote:
> On Fri, 2017-04-14 at 16:57 +0200, Dominick Grift wrote:
> > Bear with me please, because i might not fully grasp the issue (i
> > received help with diagnosing this issue):
> > 
> > This commit causes issues (and is, i think, a lousy hack):
> > e3cab998b48ab293a9962faf9779d70ca339c65d
> > 
> > The commit causes entities to "think" that SELinux is disabled after
> > "mount -o remount,ro /sys/fs/selinux
> > 
> > It is "neat" to be able to make processes "think" that selinux is
> > disabled on a selinux enabled system but not if it break anything
> > 
> > The above results in the following:
> > 
> > Systemd services that have ProtectKernelTunables=yes set in their
> > respective service units, think that SELinux is disabled.
> > 
> > However we have found that some of these services actually rely on
> > SELinux to ensure proper labeling.
> > 
> > So we have the option to make people aware that if you set
> > ProtectKernelTunables=yes that then the process cannot be SELinux-
> > aware properly, or we can just get rid of the commit above and just
> > accept that process know that SELinux is enabled.
> > 
> > Actual bug that caused me to look into this: systemd-localed selinux
> > awareness is broken due it having ProtectKernelTunables=yes in its
> > service unit
> 
> If selinuxfs is mounted read-only, then they can't use most of the
> selinuxfs interfaces, including even the ability to validate or
> canonicalize security contexts.  That will break most SELinux-aware
> services if we tell them that SELinux is enabled.  Are you sure
> systemd-localed would actually work if you told it SELinux was enabled
> when selinuxfs was mounted read-only?  What SELinux interfaces is it
> using?

AFAIK its just getfilecon/setfilecon to ensure proper labeling of various files in /etc that it creates with random names. I understand that removing ProtectKernelTunables=yes atleast makes the functionality that I identified to have been broken before work. Whether something was overlooked. I do not know.


> 
> The other question is whether ProtectKernelTunables ought to be
> mounting selinuxfs read-only.  SELinux already controls the ability to
> use its interfaces, including limiting even root, so it is unclear what
> benefit we derive from having systemd add a further restriction on top.
> 

These are questions that I cannot answer. I am not sure whether systemd mounts selinux r/o as part of ProtectKernelTunables, but I understand that it does. I agree that if it does that it should be do that in the first place.

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]