Bug 199257 - selinux options too optional
Summary: selinux options too optional
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 high
Assignee: fs_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-01 21:41 UTC by Dave Carlson
Modified: 2018-04-01 21:41 UTC (History)
0 users

See Also:
Kernel Version: 4.14, 4.15
Subsystem:
Regression: No
Bisected commit-id:


Attachments

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?

Note You need to log in before you can comment on or make changes to this bug.