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:
signature.asc
Description: PGP signature
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
