-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for forcing on selinux labels #2804
Comments
Though note that composefs will partially obviate this because the selinux labels for the content objects appear in the will be part of the erofs, not the backing filesystem. However, we still need to care about labeling for everything else - it's not going to really work to leave e.g. Ultimately...SELinux kind of breaks the core ostree design of having a data storage independent of the OS - the label for One thing that would probably help break this deadlock is to add support for "initialize-and-deploy" as a single transactional step, like:
Unlike
Then we fetch the policy from the target image, and then go back and relabel all the files/directories used up till that point. In the case where the system setting up the deployment root is the same as the target (which ideally we do in general), then we could also break this deadlock by having a build-time "default" label (root_t e.g.) and we support e.g. Hmm, and we probably want something like |
Currently when writing data for selinux systems on a non-selinux system there will be no labels. This is because `ostree_sepolicy_setfscreatecon()` just returns TRUE on non-selinux systems and xattr writing for `security.seliux` is filtered out. This patches uses the suggestion of Colin Walters (thanks!) from ostreedev#2804 and detects if the host has selinux enabled and if not just skips filtering the xattrs for selinux.
Currently when writing data for selinux systems on a non-selinux system there will be no labels. This is because `ostree_sepolicy_setfscreatecon()` just returns TRUE on non-selinux systems and xattr writing for `security.seliux` is filtered out. This patches uses the suggestion of Colin Walters (thanks!) from ostreedev#2804 and detects if the host has selinux enabled and if not just skips filtering the xattrs for selinux.
Currently when writing data for selinux systems on a non-selinux system there will be no labels. This is because `ostree_sepolicy_setfscreatecon()` just returns TRUE on non-selinux systems and xattr writing for `security.seliux` is filtered out. This patches uses the suggestion of Colin Walters (thanks!) from ostreedev#2804 and detects if the host has selinux enabled and if not just skips filtering the xattrs for selinux.
Currently when writing data for selinux systems on a non-selinux system there will be no labels. This is because `ostree_sepolicy_setfscreatecon()` just returns TRUE on non-selinux systems and xattr writing for `security.seliux` is filtered out. This patches uses the suggestion of Colin Walters (thanks!) from ostreedev#2804 and detects if the host has selinux enabled and if not just skips filtering the xattrs for selinux.
Currently when writing data for selinux systems on a non-selinux system there will be no labels. This is because `ostree_sepolicy_setfscreatecon()` just returns TRUE on non-selinux systems and xattr writing for `security.seliux` is filtered out. This patches uses the suggestion of Colin Walters (thanks!) from ostreedev#2804 and detects if the host has selinux enabled and if not just skips filtering the xattrs for selinux.
Some more on this in e.g. containers/bootc#397 - we have a warning test there and it reveals tons of missing things for this:
|
Working on containers/bootc#1 I was experimenting with testing a FCOS install from the default GHA Ubuntu VM where SELinux is disabled. ostree today doesn't work for this, but it should.
Basically, we shouldn't care about the host state, only the target. If the target system has selinux labels, we should write them. However, we have to battle libselinux which looks at
/sys/fs/selinux
etc. Our own sepolicy class also dispatches on that.Now, when we're operating on a host system that does have selinux enabled, I think it's better to use
setfscreatecon()
where we can to ensure atomicity of the security labels. But if not...I think the patches will look something like this:Basically, if the host doesn't have selinux enabled, we just write the
security.selinux
xattr the same as all other xattrs (which works fine with selinux disabled on the host).The text was updated successfully, but these errors were encountered: