Re: Cannot transition to radicale_t domain

[Bob Gustafson <bobgus@xxxxxxx>]

On 06/30/2017 12:15 PM, Juan Orti Alcaine wrote:

2017-06-30 18:07 GMT+02:00 Bob Gustafson <bobgus@xxxxxxx>:

On 06/30/2017 10:19 AM, Stephen Smalley wrote:

On Fri, 2017-06-30 at 11:07 -0400, Stephen Smalley wrote:

On Fri, 2017-06-30 at 16:39 +0200, Juan Orti Alcaine wrote:

2017-06-30 16:39 GMT+02:00 Stephen Smalley <sds@xxxxxxxxxxxxx>:

On Fri, 2017-06-30 at 16:23 +0200, Juan Orti Alcaine wrote:

2017-06-30 14:23 GMT+02:00 Juan Orti Alcaine <j.orti.alcaine@gm
ai

l.co

m>:

2017-06-30 12:42 GMT+02:00 Lukas Vrabec <lvrabec@xxxxxxxxxx>:

On 06/28/2017 09:36 AM, Thomas Mueller wrote:

Hey Juan

I'm troubleshooting the radicale policy but I cannot

figure

why the service fails to transition to radicale_t. It

runs in

the init_t domain.

  How you starting this service?

systemctl start radicale.service

I cannot find where is the problem, I see other daemons are
also
using init_daemon_domain. Why mine is it not transitioning?

What's in your unit file? Certain systemd options can prevent
SELinux
transitions or disable SELinux functionality (e.g.
NoNewPrivileges,
ProtectKernelTunables).

# /usr/lib/systemd/system/radicale.service
[Unit]
Description=Radicale CalDAV and CardDAV server
Documentation=http://radicale.org/documentation/
After=network-online.target
Requires=network-online.target

[Service]
WorkingDirectory=/var/lib/radicale
User=radicale
Group=radicale
UMask=0027
Type=forking
PIDFile=/var/run/radicale/radicale.pid
ExecStart=/usr/bin/radicale --daemon --
pid=/var/run/radicale/radicale.pid
PrivateTmp=true
PrivateDevices=true
CapabilityBoundingSet=
ProtectSystem=full
ProtectHome=true
Restart=always

[Install]
WantedBy=multi-user.target

systemd version?

I'm guessing that one of the above options is automatically enabling
NoNewPrivileges=yes and needs to be disabled.  Note to Fedora SELinux
maintainers: something needs to be done about systemd and its
handling
of NoNewPrivileges and ProtectKernelTunables, or we can only expect
more instances of such breakage...

Looks like it is PrivateDevices=true.

_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxg
To unsubscribe send an email to selinux-leave@lists.fedoraproject.org

Check out

https://bugzilla.redhat.com/show_bug.cgi?id=1412696

There the PrivateDevices=true, in combination with selinux, caused postfix to quit unexpectedly.

​That is the answer, thank you very much.

Is it a bug?​

It probably is a bug, but since there is a workaround...

It has to do with the time sequence of applying selinux magic to several directories (/dev among them) after they are mounted. Something like that anyway.

_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx