selinux: fully disable selinux-awareness for FEATURES="-selinux" #1429
Conversation
WavyEbuilder
force-pushed
the
selinux-patch
branch
from
4558584 to
01b33a8
Compare
There was a problem hiding this comment.
I think this way around is much better.
I think it came from that the visible part of profiles/features/selinux is that we turn on the USE-flag. any package that has selinux deps always has them behind teh selinux use-flag. eg chrony would have selinux? ( sec-policy/selinux-chronyd ) which gets loaded into the system-wide policy.
There are two different things that portage does regarding SELinux:
- it relabels everything in
${D}right before it merges into the live system so they have the right labels. every file on an selinux system always has a label regardless of if the package knows anything about selinux. Even if there is no app-specific policy or an selinux USE-flag you can't skip relabelling otherwise you'd be missing the basicbin_tandlswouldnt work. - The other thing that portage does is transition to a separate domain for the sandbox,
sesandboxis just an extra layer on top of the regularFEATURES=sandboxThe only time i recall having to touch sesandbox was probably when the PID namespacing rules had not yet made it into policy (easily more than a decade ago tho).
If for some reason a systems policy or policycoreutils are completely broken, then the path to fix it all would be rebuild but dont relabel, then once everything is rebuilt you relabel the entire system. FEATURES="-selinux" emerge -av @world makes most sense to me for that. the sesandbox would also be disabled in that case and thats fine. I can think of cases where you want portage to label but the sandbox interferes, i cant really think of a case where you'd use the sesandbox but would skip relabelling.
|
LGTM, but @WavyEbuilder, can you include some of perfinion's comment in your commit message too? |
Will do |
USE is not really appropriate for toggling SELinux awareness as it is
not really package-related. Current SELinux profiles already set
FEATURES="selinux", so no changes are required in ::gentoo.
Portage currently has two main features of SELinux awareness:
- Relabeling all objects in ${D} before merging to the system root to
ensure correct labeling. This is not possible if the system's filecon
specs are broken, as portage would be unable to calculate the context
needed to be applied to objects.
- Transitioning the package build run in sandbox to a SELinux sandbox
domain specified by PORTAGE_SANDBOX_T. This however already has its
own feature, FEATURES="sesandbox".
Hence, pivot over to FEATURES="selinux" for all operations that take
place on filesystem objects.
It should be expected that FEATURES="-selinux" will completely disable
selinux awareness; the system administrator should be able to recover
from a situation where labeling is invalid using portage without having
to fully disabling SELinux from being loaded by the kernel.
This is useful for recovery situations where a core SELinux component
is broken, such as:
- policycoreutils
- system policy
- filesystem labelling
In those cases, as all SELinux awareness for portage can be turned off,
FEATURES="-selinux" has no additional requirements for a functioning
portage on SELinux systems, making it possible to fix broken SELinux
installations.
Signed-off-by: Rahul Sandhu <[email protected]>
WavyEbuilder
force-pushed
the
selinux-patch
branch
from
01b33a8 to
af2c7ab
Compare
It should be expected that FEATURES="-selinux" will completely disable selinux awareness; the system administrator should be able to recover from a situation where labeling is invalid using portage without having to fully disabling SELinux from being loaded by the kernel.