Cannot transition to radicale_t domain

[Juan Orti Alcaine]

Hi,

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.

Could anybody give a look to the policy to check if there is something
wrong? I don't know what can be the problem.

Thank you.

http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.te
http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.fc
http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.if

[Thomas Mueller]

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.
>
>
>  http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.te
>  http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.fc
>  http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.if 
is your module loaded? (semodule -l | grep radicale)

Do your files have correct labels? (ls -lZ /usr/bin/radicale )?


>   allow radicale_t bin_t:file execute; 
might better use the corecmd_exec_bin()

http://oss.tresys.com/docs/refpolicy/api/kernel_corecommands.html#link_co...

>  files_type(radicale_etc_t); 
maybe better use files_config_file()

http://oss.tresys.com/docs/refpolicy/api/kernel_files.html#link_files_con...

- Thomas

[Lukas Vrabec]

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?

Lukas

> >
> > http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.te
> > http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.fc
> > http://pkgs.fedoraproject.org/cgit/rpms/radicale.git/plain/radicale.if
>  
>  is your module loaded? (semodule -l | grep radicale)
>  
>  Do your files have correct labels? (ls -lZ /usr/bin/radicale )?
>  
>  
>   >  allow radicale_t bin_t:file execute;
>  
>  might better use the corecmd_exec_bin()
>  
>  http://oss.tresys.com/docs/refpolicy/api/kernel_corecommands.html#link_co...
>  
>   > files_type(radicale_etc_t);
>  
>  maybe better use files_config_file()
>  
>  http://oss.tresys.com/docs/refpolicy/api/kernel_files.html#link_files_con...
>  
>  - Thomas
>  
>  
>  _______________________________________________
>  selinux mailing list -- selinux(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
>   

-- 
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

[Juan Orti Alcaine]

2017-06-30 12:42 GMT+02:00 Lukas Vrabec <lvrabec(a)redhat.com&gt;:

>  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​​

[Juan Orti Alcaine]

2017-06-30 14:23 GMT+02:00 Juan Orti Alcaine <j.orti.alcaine(a)gmail.com&gt;:

>  2017-06-30 12:42 GMT+02:00 Lukas Vrabec <lvrabec(a)redhat.com&gt;:
>
> > 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?

I guess this should be enough:

type radicale_t;
type radicale_exec_t;
init_daemon_domain(radicale_t, radicale_exec_t)
​
​But I get AVCs like these:

SELinux is preventing radicale from ioctl access on the file
/usr/bin/radicale.

*****  Plugin catchall (100. confidence) suggests
**************************

If you believe that radicale should be allowed ioctl access on the radicale
file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'radicale' --raw | audit2allow -M my-radicale
# semodule -X 300 -i my-radicale.pp


Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:radicale_exec_t:s0
Target Objects                /usr/bin/radicale [ file ]
Source                        radicale
Source Path                   radicale
Port                          <Unknown>
Host                          xenon
Source RPM Packages
Target RPM Packages
Policy RPM                    <Unknown>
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     xenon
Platform                      Linux xenon 4.11.6-301.fc26.x86_64 #1 SMP Tue
Jun
                              20 16:17:33 UTC 2017 x86_64 x86_64
Alert Count                   39
First Seen                    2017-06-27 19:39:30 CEST
Last Seen                     2017-06-30 15:49:43 CEST
Local ID                      a3b3d3eb-d7ba-4e1f-a1eb-c46409986dfb

Raw Audit Messages
type=AVC msg=audit(1498830583.883:418): avc:  denied  { ioctl } for
pid=11577 comm="radicale" path="/usr/bin/radicale"
dev="dm-0" ino=1973935
ioctlcmd=0x5401 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:radicale_exec_t:s0 tclass=file permissive=0


Hash: radicale,init_t,radicale_exec_t,file,ioctl

------------------------------

SELinux is preventing radicale from read access on the file
/etc/radicale/config.

*****  Plugin catchall (100. confidence) suggests
**************************

If you believe that radicale should be allowed read access on the config
file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'radicale' --raw | audit2allow -M my-radicale
# semodule -X 300 -i my-radicale.pp


Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:radicale_etc_t:s0
Target Objects                /etc/radicale/config [ file ]
Source                        radicale
Source Path                   radicale
Port                          <Unknown>
Host                          xenon
Source RPM Packages
Target RPM Packages
Policy RPM                    <Unknown>
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     xenon
Platform                      Linux xenon 4.11.6-301.fc26.x86_64 #1 SMP Tue
Jun
                              20 16:17:33 UTC 2017 x86_64 x86_64
Alert Count                   10
First Seen                    2017-06-27 19:39:30 CEST
Last Seen                     2017-06-30 15:49:43 CEST
Local ID                      77f4e686-55dc-49d3-a01c-a5c3caac9959

Raw Audit Messages
type=AVC msg=audit(1498830583.859:412): avc:  denied  { read } for
pid=11577 comm="radicale" name="config" dev="dm-0"
ino=1201229
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:radicale_etc_t:s0 tclass=file permissive=0


Hash: radicale,init_t,radicale_etc_t,file,read

[Stephen Smalley]

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(a)gmail.co
>  m>:
>  > 2017-06-30 12:42 GMT+02:00 Lukas Vrabec <lvrabec(a)redhat.com&gt;:
>  > > 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).

> 
> I guess this should be enough:
> 
> type radicale_t;
> type radicale_exec_t;
> init_daemon_domain(radicale_t, radicale_exec_t)
> 
> But I get AVCs like these:
> 
> SELinux is preventing radicale from ioctl access on the file
> /usr/bin/radicale.
> 
> *****  Plugin catchall (100. confidence) suggests  
> **************************
> 
> If you believe that radicale should be allowed ioctl access on the
> radicale file by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # ausearch -c 'radicale' --raw | audit2allow -M my-radicale
> # semodule -X 300 -i my-radicale.pp
> 
> 
> Additional Information:
> Source Context                system_u:system_r:init_t:s0
> Target Context                system_u:object_r:radicale_exec_t:s0
> Target Objects                /usr/bin/radicale [ file ]
> Source                        radicale
> Source Path                   radicale
> Port                          <Unknown>
> Host                          xenon
> Source RPM Packages
> Target RPM Packages
> Policy RPM                    <Unknown>
> Selinux Enabled               True
> Policy Type                   targeted
> Enforcing Mode                Enforcing
> Host Name                     xenon
> Platform                      Linux xenon 4.11.6-301.fc26.x86_64 #1
> SMP Tue Jun
>                               20 16:17:33 UTC 2017 x86_64 x86_64
> Alert Count                   39
> First Seen                    2017-06-27 19:39:30 CEST
> Last Seen                     2017-06-30 15:49:43 CEST
> Local ID                      a3b3d3eb-d7ba-4e1f-a1eb-c46409986dfb
> 
> Raw Audit Messages
> type=AVC msg=audit(1498830583.883:418): avc:  denied  { ioctl } for 
> pid=11577 comm="radicale" path="/usr/bin/radicale"
dev="dm-0"
> ino=1973935 ioctlcmd=0x5401 scontext=system_u:system_r:init_t:s0
> tcontext=system_u:object_r:radicale_exec_t:s0 tclass=file
> permissive=0
> 
> 
> Hash: radicale,init_t,radicale_exec_t,file,ioctl
> 
> ------------------------------
> 
> SELinux is preventing radicale from read access on the file
> /etc/radicale/config.
> 
> *****  Plugin catchall (100. confidence) suggests  
> **************************
> 
> If you believe that radicale should be allowed read access on the
> config file by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # ausearch -c 'radicale' --raw | audit2allow -M my-radicale
> # semodule -X 300 -i my-radicale.pp
> 
> 
> Additional Information:
> Source Context                system_u:system_r:init_t:s0
> Target Context                system_u:object_r:radicale_etc_t:s0
> Target Objects                /etc/radicale/config [ file ]
> Source                        radicale
> Source Path                   radicale
> Port                          <Unknown>
> Host                          xenon
> Source RPM Packages
> Target RPM Packages
> Policy RPM                    <Unknown>
> Selinux Enabled               True
> Policy Type                   targeted
> Enforcing Mode                Enforcing
> Host Name                     xenon
> Platform                      Linux xenon 4.11.6-301.fc26.x86_64 #1
> SMP Tue Jun
>                               20 16:17:33 UTC 2017 x86_64 x86_64
> Alert Count                   10
> First Seen                    2017-06-27 19:39:30 CEST
> Last Seen                     2017-06-30 15:49:43 CEST
> Local ID                      77f4e686-55dc-49d3-a01c-a5c3caac9959
> 
> Raw Audit Messages
> type=AVC msg=audit(1498830583.859:412): avc:  denied  { read } for 
> pid=11577 comm="radicale" name="config" dev="dm-0"
ino=1201229
> scontext=system_u:system_r:init_t:s0
> tcontext=system_u:object_r:radicale_etc_t:s0 tclass=file permissive=0
> 
> 
> Hash: radicale,init_t,radicale_etc_t,file,read
> 
> 
> 
> _______________________________________________
> selinux mailing list -- selinux(a)lists.fedoraproject.org
> To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org

[Juan Orti Alcaine]

2017-06-30 16:39 GMT+02:00 Stephen Smalley <sds(a)tycho.nsa.gov&gt;:

>  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(a)gmail.co
>  > m>:
>  > > 2017-06-30 12:42 GMT+02:00 Lukas Vrabec <lvrabec(a)redhat.com&gt;:
>  > > > 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
​

[Stephen Smalley]

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&gt;:
>  > 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@gmai
>  > l.co
>  > > m>:
>  > > > 2017-06-30 12:42 GMT+02:00 Lukas Vrabec <lvrabec(a)redhat.com&gt;:
>  > > > > 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...

[Stephen Smalley]

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&gt;:
>  > > 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(a)redhat.com&gt;:
>  > > > > > 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.

[Bob Gustafson]

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&gt;:
> >>> 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(a)redhat.com&gt;:
> >>>>>> 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.

[Juan Orti Alcaine]

2017-06-30 18:07 GMT+02:00 Bob Gustafson <bobgus(a)rcn.com&gt;:

>  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&gt;:
> >>>
> >>>> 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(a)redhat.com&gt;:
> >>>>>>
> >>>>>>> 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?​

[Bob Gustafson]

On 06/30/2017 12:15 PM, Juan Orti Alcaine wrote:
>  2017-06-30 18:07 GMT+02:00 Bob Gustafson <bobgus(a)rcn.com 
>  <mailto:[e-mail]>>:
>
>
>
>      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 <mailto:[e-mail]>>:
>
>                      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 <http://l.co>
>
>                          m>:
>
>                              2017-06-30 12:42 GMT+02:00 Lukas Vrabec
>                              <lvrabec(a)redhat.com
>                              <mailto:[e-mail]>>:
>
>                                  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/
>                  <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
>          <mailto:[e-mail]>
>          To unsubscribe send an email to
>          selinux-leave(a)lists.fedoraproject.org
>          <mailto:[e-mail]>
>
>      Check out
>
>      https://bugzilla.redhat.com/show_bug.cgi?id=1412696
>      <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.

[Stephen Smalley]

On Fri, 2017-06-30 at 19:15 +0200, Juan Orti Alcaine wrote:
>  2017-06-30 18:07 GMT+02:00 Bob Gustafson <bobgus(a)rcn.com&gt;:
>  > 
>  > 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.