Bug 2208162

Karle,

It seems unusual systemd wants to handle tmpfs files.
Were there any related configuration changes made?
Did it start to happen right after the package update?
How does the triggering service look like?
Does RHEL 9 suffer from the same issue?

Hi Zdenek,
I think this is because now we are running pkcsslotd as a regular user and not root. This was accompanied with some unit file changes I guess. Could you please take a look at the service file inside opencryptoki-3.21.0-2.el8, maybe you find your answers there.

I did the same findings as Milos. Pasting here for completeness, although it is sort of duplicate.

# setenforce 0
# systemctl start pkcsslotd
# ausearch -m avc 
----
time->Thu May 18 05:05:03 2023
type=AVC msg=audit(1684400703.589:1104): avc:  denied  { unlink } for  pid=1 comm="systemd" name="var.lib.opencryptoki.swtok" dev="tmpfs" ino=42503 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:pkcs_slotd_tmpfs_t:s0 tclass=file permissive=1
----
time->Thu May 18 05:05:08 2023
type=PROCTITLE msg=audit(1684400708.895:1105): proctitle="/usr/sbin/pkcsslotd"
type=PATH msg=audit(1684400708.895:1105): item=0 name="/lib64/ld-linux-x86-64.so.2" inode=10411 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1684400708.895:1105): cwd="/"
type=EXECVE msg=audit(1684400708.895:1105): argc=1 a0="/usr/sbin/pkcsslotd"
type=SYSCALL msg=audit(1684400708.895:1105): arch=c000003e syscall=59 success=yes exit=0 a0=564d7765de10 a1=564d7765e570 a2=564d776179b0 a3=0 items=1 ppid=1 pid=10231 auid=4294967295 uid=994 gid=991 euid=994 suid=994 fsuid=994 egid=991 sgid=991 fsgid=991 tty=(none) ses=4294967295 comm="pkcsslotd" exe="/usr/sbin/pkcsslotd" subj=system_u:system_r:pkcs_slotd_t:s0 key=(null)
type=AVC msg=audit(1684400708.895:1105): avc:  denied  { nnp_transition } for  pid=10231 comm="(kcsslotd)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:pkcs_slotd_t:s0 tclass=process2 permissive=1
----
time->Thu May 18 05:05:08 2023
type=PROCTITLE msg=audit(1684400708.910:1106): proctitle="/usr/sbin/pkcsslotd"
type=CAPSET msg=audit(1684400708.910:1106): pid=10231 cap_pi=0 cap_pp=0 cap_pe=0 cap_pa=0
type=SYSCALL msg=audit(1684400708.910:1106): arch=c000003e syscall=126 success=yes exit=0 a0=55adee3d7774 a1=55adee3d777c a2=55adee3d777c a3=0 items=0 ppid=1 pid=10231 auid=4294967295 uid=994 gid=991 euid=994 suid=994 fsuid=994 egid=991 sgid=991 fsgid=991 tty=(none) ses=4294967295 comm="pkcsslotd" exe="/usr/sbin/pkcsslotd" subj=system_u:system_r:pkcs_slotd_t:s0 key=(null)
type=AVC msg=audit(1684400708.910:1106): avc:  denied  { setcap } for  pid=10231 comm="pkcsslotd" scontext=system_u:system_r:pkcs_slotd_t:s0 tcontext=system_u:system_r:pkcs_slotd_t:s0 tclass=process permissive=1

In permissive pkcsslotd is running as 
# ps -eZ | grep pkcsslotd
system_u:system_r:pkcs_slotd_t:s0 10232 ?        00:00:00 pkcsslotd
while in enforcing it is 
# ps -eZ | grep pkcsslotd
system_u:system_r:init_t:s0       10254 ?        00:00:00 pkcsslotd

With pkcsslotd running in the proper domain (in permissive) I didn't see AVCs reported in the original bug description.

So I guess it is actually the transition that's needs to be fixed/allowed.

I took a bit deeper dive, here are my findings, feel free to correct me if I am wrong.

The pkcslotd service unit in the updated opencrcyptoki package utilizes numerous systemd features for sandboxing and securing. In particular, these directives require being backed by selinux-policy:

NoNewPrivileges=yes
CapabilityBoundingSet=~CAP_SETUID CAP_SETGID CAP_SETPCAP
User=pkcsslotd
RemoveIPC=yes

This module helped me (no tmpfs in my case, but my scenario may be incomplete):
(allow init_t pkcs_slotd_t (process2 (nnp_transition)))
(allow pkcs_slotd_t pkcs_slotd_t (process (setcap)))
(allow init_t pkcs_slotd_t (shm (destroy)))
1. To start the service in the correct domain
2. To start the service successfully, yet report problems
3. To start and stop the service without any issue

The cleanup is made by systemd (PID 1). Depending on which features were actually used, init_t needs to be able to
- remove shared memory files (*_tmpfs_t)
- remove semaphores
- remove msgq

My secondary finding is that pkcsslotd is probably the first service which uses some of the User/Group/DynamicUser/RemoveIPC settings and at the same time uses IPC objects which remain present after the service stops. First one in RHEL 8, RHEL 9, and even Fedora.

RemoveIPC=

    Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and group the processes of this unit are run as are removed when the unit is stopped. This setting only has an effect if at least one of User=, Group= and DynamicUser= are used. It has no effect on IPC objects owned by the root user. Specifically, this removes System V semaphores, as well as System V and POSIX shared memory segments and message queues. If multiple units use the same user or group the IPC objects are removed when the last of these units is stopped. This setting is implied if DynamicUser= is set.

NoNewPrivileges=

    Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that a process and its children can never elevate privileges again. Defaults to false, but certain settings override this and ignore the value of this setting. This is the case when DynamicUser=, LockPersonality=, MemoryDenyWriteExecute=, PrivateDevices=, ProtectClock=, ProtectHostname=, ProtectKernelLogs=, ProtectKernelModules=, ProtectKernelTunables=, RestrictAddressFamilies=, RestrictNamespaces=, RestrictRealtime=, RestrictSUIDSGID=, SystemCallArchitectures=, SystemCallFilter=, or SystemCallLog= are specified. Note that even if this setting is overridden by them, systemctl show shows the original value of this setting. In case the service will be run in a new mount namespace anyway and SELinux is disabled, all file systems are mounted with MS_NOSUID flag. Also see No New Privileges Flag.

FYI, I have copied the bug for RHEL-9 as bug 2209235.

I haven't managed to catch the denials with pkcs_slotd_tmpfs_t as reported, this is the needed policy:

(allow pkcs_slotd_t pkcs_slotd_t (capability (setgid setuid)))
(allow pkcs_slotd_t self (process (setcap)))
(allow init_t pkcs_slotd_t (process2 (nnp_transition)))
(allow init_t pkcs_slotd_t (shm (destroy)))
(filecon "/var/run/opencryptoki(/.*)?" any (system_u object_r pkcs_slotd_var_run_t ((s0) (s0))))

Karle,
Do you know which particular action triggers creating and removing the files like /dev/shm/var.lib.opencryptoki.lite, or if there is any other setup change needed?

(In reply to Zdenek Pytela from comment #12)
> I haven't managed to catch the denials with pkcs_slotd_tmpfs_t as reported,

Me neither (in permissive). Looking at the timestamp, I guess that comes from enforcing mode that was enabled earlier and I have accidentally copied it.

(In reply to Karel Srot from comment #13)
> (In reply to Zdenek Pytela from comment #12)
> > I haven't managed to catch the denials with pkcs_slotd_tmpfs_t as reported,
> 
> Me neither (in permissive). Looking at the timestamp, I guess that comes
> from enforcing mode that was enabled earlier and I have accidentally copied
> it.

It does not matter from when the denials are, just need to know how it reproduces.
Allowing the shm-related denials makes sense, but I am unable to get to them with any combination of policy and opencryptoki, updated in different order etc.

It seems to be done because of the clean up I am doing between tests

# systemctl stop pkcsslotd
# find /var/lib/opencryptoki/ -type f -exec rm {} \; 
# rm -f /dev/shm/var.lib.opencryptoki.*
# systemctl start pkcsslotd
# ausearch -m avc -ts recent
----
time->Thu May 25 06:01:50 2023
type=AVC msg=audit(1685008910.761:321): avc:  denied  { unlink } for  pid=1 comm="systemd" name="var.lib.opencryptoki.swtok" dev="tmpfs" ino=39400 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:pkcs_slotd_tmpfs_t:s0 tclass=file permissive=0
----
time->Thu May 25 06:02:11 2023
type=PROCTITLE msg=audit(1685008931.677:322): proctitle="/usr/sbin/pkcsslotd"
type=PATH msg=audit(1685008931.677:322): item=0 name="/lib64/ld-linux-x86-64.so.2" inode=10411 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1685008931.677:322): cwd="/"
type=EXECVE msg=audit(1685008931.677:322): argc=1 a0="/usr/sbin/pkcsslotd"
type=SYSCALL msg=audit(1685008931.677:322): arch=c000003e syscall=59 success=yes exit=0 a0=56334e4cc070 a1=56334e41f480 a2=56334e559f30 a3=0 items=1 ppid=1 pid=6324 auid=4294967295 uid=994 gid=991 euid=994 suid=994 fsuid=994 egid=991 sgid=991 fsgid=991 tty=(none) ses=4294967295 comm="pkcsslotd" exe="/usr/sbin/pkcsslotd" subj=system_u:system_r:init_t:s0 key=(null)
type=SELINUX_ERR msg=audit(1685008931.677:322): op=security_bounded_transition seresult=denied oldcontext=system_u:system_r:init_t:s0 newcontext=system_u:system_r:pkcs_slotd_t:s0
type=AVC msg=audit(1685008931.677:322): avc:  denied  { nnp_transition } for  pid=6324 comm="(kcsslotd)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:pkcs_slotd_t:s0 tclass=process2 permissive=0

This permission is required in cases a token was initialized:
(allow init_t pkcs_slotd_tmpfs_t (file (unlink)))

I just dont understand why any IPC means are removed on the service *start* while it should be on stopping with RemoveIPC in place.

One more required for the update of a running service:
(allow pkcs_slotd_t pkcs_slotd_exec_t (file (execute_no_trans)))
which looks like reexec, but it was not sufficient and actually the service restart was needed - perhaps there will be some other adjustment needed on opencryptoki side?

# systemctl status pkcsslotd -l
● pkcsslotd.service - Daemon which manages cryptographic hardware tokens for the openCryptoki package
   Loaded: loaded (/usr/lib/systemd/system/pkcsslotd.service; disabled; vendor preset: disabled)
   Active: failed (Result: timeout) since Thu 2023-05-25 09:24:48 EDT; 1min 33s ago
 Main PID: 9321 (code=exited, status=0/SUCCESS)

May 25 09:23:18 ci-vm-10-0-139-159.hosted.upshift.rdu2.redhat.com systemd[1]: pkcsslotd.service: Succeeded.
May 25 09:23:18 ci-vm-10-0-139-159.hosted.upshift.rdu2.redhat.com systemd[1]: Stopped Daemon which manages cryptographic hardware tokens for the openCryptoki package.
May 25 09:23:18 ci-vm-10-0-139-159.hosted.upshift.rdu2.redhat.com systemd[1]: Starting Daemon which manages cryptographic hardware tokens for the openCryptoki package...
May 25 09:23:18 ci-vm-10-0-139-159.hosted.upshift.rdu2.redhat.com systemd[1]: pkcsslotd.service: Can't open PID file /run/pkcsslotd.pid (yet?) after start: No such file or directory
May 25 09:24:48 ci-vm-10-0-139-159.hosted.upshift.rdu2.redhat.com systemd[1]: pkcsslotd.service: start operation timed out. Terminating.
May 25 09:24:48 ci-vm-10-0-139-159.hosted.upshift.rdu2.redhat.com systemd[1]: pkcsslotd.service: Failed with result 'timeout'.
May 25 09:24:48 ci-vm-10-0-139-159.hosted.upshift.rdu2.redhat.com systemd[1]: Failed to start Daemon which manages cryptographic hardware tokens for the openCryptoki package.

So the complete policy now looks like this:

(filecon "/var/run/opencryptoki(/.*)?" any (system_u object_r pkcs_slotd_var_run_t ((s0) (s0))))
(allow pkcs_slotd_t pkcs_slotd_t (capability (setgid setuid)))
(allow pkcs_slotd_t pkcs_slotd_t (process (setcap)))
(allow pkcs_slotd_t pkcs_slotd_exec_t (file (execute_no_trans)))
(allow init_t pkcs_slotd_t (process2 (nnp_transition)))
(allow init_t pkcs_slotd_t (shm (destroy)))
(allow init_t pkcs_slotd_tmpfs_t (file (unlink)))
(allow httpd_t httpd_t (capability (ipc_owner)))

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:7091