Bug 199257

Summary:	selinux options too optional
Product:	File System	Reporter:	Dave Carlson (thecubic)
Component:	Other	Assignee:	fs_other
Status:	NEW ---
Severity:	high
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.14, 4.15	Subsystem:
Regression:	No	Bisected commit-id:

Description Dave Carlson 2018-04-01 21:41:48 UTC

Using Fedora 27, fully updated
SElinux enabled (enforcing / targeted) by default
Move to permissive / targeted as is tradition
setroubleshootd still tryhards on auditing, burning CPU
Switch to disabled

This broke docker.  Changing kernels back to 4.14 did not help, removing the selinux-enabled flag also did not help.  Overlayfs in the kernel explodes here:
https://github.com/torvalds/linux/blob/master/fs/overlayfs/super.c#L515

> overlayfs: unrecognized mount option "context=<some selinux context>"...

This is because, when disabled, the mount options no longer are intercepted by the selinux-layer (which "sits above" the true fs options), so when it is disabled they propagate down to the FS which now balks at a mount option it by definition has never seen before.

There's a defect somewhere in the stack that it still passes context= (maybe because it's still labeled?), however not covering selinux options regardless of selinux state only accomplishes bad things:

- selinux options are usually intercepted (lol) so fs driver writers need to avoid them as reserved options
- there is no workaround except re-enabling selinux if a caller passes context
(yes, I'm using said unfortunate workaround)

Could selinux options be considered "sloppy"?  As in, if selinux is disabled it still registers the option (therefore, mount success), but selinux hooks (knowing the state) turn into no-ops?