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.

Ok, done: https://bugzilla.redhat.com/show_bug.cgi?id=1468846

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.

Please see https://bugzilla.redhat.com/show_bug.cgi?id=1714600#c1

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