2017-06-30 18:07 GMT+02:00 Bob Gustafson <bobgus(a)rcn.com>:
>
> 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(a)tycho.nsa.gov
> > > > >:
> > > > > 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.alca
> > > > > > ine@gm
> > > > > > ai
> > > > > >
> > > > > l.co
> > > > > > m>:
> > > > > > > 2017-06-30 12:42 GMT+02:00 Lukas Vrabec
<lvrabec@redhat
> > > > > > > .com>:
> > > > > > > > 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to selinux-leave(a)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?
At present, assuming that systemd is operating as intended, I would say
it is a bug in radicale's unit file on Fedora. They need to drop
PrivateDevices=true for it (and any other service); otherwise no
SELinux domain transition will happen. An unfortunate tradeoff to have
to make though.