Bug 1293493

clamav-milter is not transitioning to antivirus_t

Hi, 
Could you attach output of:
# ps -efZ | grep init_t 

Thank you.

Here you go:

system_u:system_r:init_t:s0     root         1     0  0 Jan03 ?        00:00:14 /usr/lib/systemd/systemd --switched-root --system --deserialize 21
system_u:system_r:init_t:s0     clamilt   1412     1  0 Jan03 ?        00:00:00 /usr/sbin/clamav-milter -c /etc/mail/clamav-milter.conf --nofork=yes
system_u:system_r:init_t:s0     john      1901     1  0 Jan03 ?        00:00:00 /usr/lib/systemd/systemd --user
system_u:system_r:init_t:s0     john      1905  1901  0 Jan03 ?        00:00:00 (sd-pam)
system_u:system_r:init_t:s0     root     10062     1  0 Jan04 ?        00:00:00 /usr/lib/systemd/systemd-machined
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 john 30972 12818  0 17:58 pts/0 00:00:00 grep --color=auto init_t

As mentioned in bug #1292227, I think something with the new clamav-milter.service items is triggering this:

+User=clamilt
+Group=clamilt
+
+PrivateTmp=yes
+PrivateDevices=yes
+NoNewPrivileges=yes
+CapabilityBoundingSet=CAP_KILL
+
+ReadOnlyDirectories=/etc
+ReadOnlyDirectories=/usr
+ReadOnlyDirectories=/var/lib

What does 

ls -Z /usr/sbin/clamav-milter

show you?

Here you go:

system_u:object_r:antivirus_exec_t:s0 /usr/sbin/clamav-milter

It appears that removing:

NoNewPrivileges=yes

allows it to transition to antivirus_t.

Let's see what the systemd folks have to say about this.

In order to make this work, you need to make 

typebounds init_t antivirus_t;
allow init_t antivirus_exec_t:file entrypoint;

So, I tried:

module av 1.0;

require {
        type init_t;
        type antivirus_t;
        type antivirus_exec_t;
        class file { entrypoint };
}

typebounds init_t antivirus_t;
allow init_t antivirus_exec_t:file entrypoint;


But clamav-milter still doesn't transition to antivirus_t with NoNewPrivileges=yes.

I guess at this point I'll just pull NoNewPrivileges=yes from the service file, but I would really like some more information from systemd and/or selinux people as to whether or not that it is expected that this statement should interfere with SELinux transitions.

I've also tried:

SELinuxContext=system_u:system_r:antivirus_t:s0

in the clamav-milter.service, but it fails to start with that for no reason that I can discern other than:

systemd[4464]: Failed at step EXEC spawning /usr/sbin/clamav-milter: Operation not permitted

even in permissive mode.

To be clear - this last tests were done on EL7.

I failed to see any discussion from comment 10 on this so I reported https://github.com/systemd/systemd/issues/3845. It appears other packagers are having same troubles https://jira.mariadb.org/browse/MDEV-10404

https://github.com/systemd/systemd/issues/3852 Systemd bug report on Selinuxcontext and NoNewPrivileges=yes incompatibility. Great work Orion.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. 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 '23'.

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 23 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.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.