Bug 1467103
| Summary: | restorecon must also fix the context of mountpoints (or pid1 must be able to mount anything anywhere) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Zbigniew Jędrzejewski-Szmek <zbyszek> |
| Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | a.dobrawy, bobgus, dwalsh, jorti, lnykryn, lvrabec, marek.gresko, mgrepl, mschorm, msekleta, plautrba, ssahani, s, systemd-maint, vmojzis, zbyszek, zpytela |
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-3.14.4-30.fc31 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-10-31 17:52:27 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1706451, 1712935, 1714600 | ||
|
Description
Zbigniew Jędrzejewski-Szmek
2017-07-02 21:14:34 UTC
All my services in F26 with PrivateDevices=true fail because the SELinux transition from init_t to the daemon domain is blocked, rendering the PrivateDevices directive unusable. The services worked in F25, so something has changed between versions. Juan, that probably deserves a separate bug report. This one is a tooling RFE. This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'. This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Can I get some update on the isuue here, please? I've also ran into it. The procedure in https://bugzilla.redhat.com/show_bug.cgi?id=1714600#c1 is fine as a manual workaround when creating an OS image, but is not suitable for end users who need to fully relabel an existing installation they are running from. E.g. they get AVCs, reboot in permissive mode to do a relabel, and reboot the machine in enforcing mode. The expectation is that touching /.autorelabel is enough to do a full relabel. Asking people to fiddle with bind mounts to do a relabel is not appropriate. Right now people think they do a full relabel, no errors or changes are reported, but they still get AVCs because of mislabeled mount points. Sorry, but the selinux tool that is used for automatic relabelling just needs to handle this automatically. restorecon can't do manipulate mount points itself. Either systemd needs to manage this before it covers parts of potentially unlabeled fs with another fs like devtmpfs on /dev. Or systemd needs to be allowed to mount on unlabeled_fs mount points - https://bugzilla.redhat.com/show_bug.cgi?id=1714600 > Or systemd needs to be allowed to mount on unlabeled_fs mount points - https://bugzilla.redhat.com/show_bug.cgi?id=1714600 This would help for that particular bug, but the labels that those directories have is not always unlabeled, sometimes it's some other wrong value. So this doesn't really solve the issue. > Either systemd needs to manage this before it covers parts of potentially unlabeled fs This would mean that systemd would be need permission to relabel any directory. I don't think relabelling the filesystem really belongs in the manager. > restorecon can't do manipulate mount points itself. restorecon needs to unshare the mount namespace, and do mount point manipulation privately. This surely can be done. (In reply to Zbigniew Jędrzejewski-Szmek from comment #10) > This would help for that particular bug, but the labels that those > directories have is not > always unlabeled, sometimes it's some other wrong value. So this doesn't > really solve the > issue. The issue is that systemd tries to mount something on unlabeled mount point, not that there's unlabeled fs under already mounted fs. E.g. unlabeled /dev - systemd mounts /dev/ in initramfs when selinux policy is not loaded yet so policy can't be enforced, /dev/ is mounted and everything works as expected even though under mounted /dev/ is unlabeled /dev But when systemd tries to do the same thing after the policy is loaded, e.g. as part of PrivateDevices feature, unlabeled /dev/ is taken from original / and systemd aka init_t is not allowed to use this as mount point. So if we allowed init_t to mount on any mountpoint, it would fix this problem completely. > So if we allowed init_t to mount on any mountpoint, it would fix this problem completely.
Ack, that would work too. But please note that this gives systemd the possibility
to replace *anything* in the file system. Not sure if that's acceptable from selinux POV.
This either needs a policy change as described in https://bugzilla.redhat.com/show_bug.cgi?id=1467103#c11, or making restorecon smarter as described in https://bugzilla.redhat.com/show_bug.cgi?id=1467103#c0. Reassigning back to selinux. Please let me know if we should change something in systemd. Hi All, We have fixes for this in SELinux policy in Fedora 31+ branches. https://github.com/fedora-selinux/selinux-policy/commit/b313a79dbfd2fba545e00f31aa53d29c6f2b2722 This issue is also connected to following discussion with systemd folks: https://github.com/fedora-selinux/selinux-policy/issues/270 Builds for Fedora Rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1354299 Will an upgrade to Fedora 31 (after Tuesday) be successful in resolving this problem? i.e., has it been tested? I also look forward to this fix. I also want to know, if the fixed package is already part of the F31 official installation media (e.g. from getfedora.org), or if it si only available as an F31 update, or not available in F31 at all yet. Or point us please, to the oldest released build for F31 which contain fix for this issue. --- The F31 Cinnamon DE installation live image conatins "selinux-policy-3.14.4-37" which seems older than "selinux-policy-3.14.4-31.fc32" you mentioned in the c#14. Right now the latest update in F31 seems to be "3.14.4-39". Hi All, This fix was introduced in selinux-policy-3.14.4-30.fc31 in 2019-08-13: https://koji.fedoraproject.org/koji/buildinfo?buildID=1354300 So it means yes, fix is included in selinux-policy-3.14.4-37.fc31 which is part of installation image. Awesome, thanks for the info |