Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: After installing snapd and enabling the spamassasin daemon, spamd (the spamassassin daemon) gets an AVC denial when attempting to search the snap binary directory '/var/lib/snapd/snap/bin'. May 16 09:03:52 <host> audit[1145]: AVC avc: denied { search } for pid=1145 comm="spamd" name="snapd" dev="vda5" ino=48000 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:snappy_var_lib_t:s0 tclass=dir permissive=0 There are various components involved so I will attempt to summarize my findings and let you decide which component needs changing: 1. Someone, somehow, adds '/var/lib/snapd/snap/bin' to system path environment. I have no idea where or how - it seems to be present in the search path even without snap installed. I would have thought it would be included only after snap installed, but even on fedora 38 without snap installed I see: sudo systemd-path search-binaries -> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin The thing is, without the directory present and tagged with a context, there is no avc denial. 2. When snapd is installed, and at least one snap app is installed, it creates the directory '/var/lib/snapd/snap/bin' with context snappy_var_lib_t ls -Z -d /var/lib/snapd/snap/bin -> system_u:object_r:snappy_var_lib_t:s0 3. On startup, Spamd examines all directories in its PATH variable and filters those non-existant and inaccessible paths and builds a new path for itself and its spawned children. This is done in '/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Util.pm' - function clean_path_in_taint_mode. It's the examination of components of PATH that results in the denial. I don't know which changes are needed. Personally, I don't really like snap adding a directory to path that seems to be passed to every system process. For item 3, the spamd environment can be modified by explicitly setting PATH= in '/etc/sysconfig/spamassassin'. And perhaps the selinux package should allow search access of the directory it includes as a default executable directory. Hopefully you can direct this problem to the appropriate destination. Version-Release number of selected component (if applicable): spamassassin-4.0.0-3.fc38.x86_64 selinux-policy-38.12-1.fc38.noarch selinux-policy-targeted-38.12-1.fc38.noarch snapd-selinux-2.58.3-1.fc38.noarch snapd-2.58.3-1.fc38.x86_64 How reproducible: Always Steps to Reproduce: 1. Check systemd binaries path (on root): sudo systemd-path search-binaries-default -> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin sudo systemd-path search-binaries -> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin 2. Install spamassassin & snap: sudo dnf install spamassassin snapd 3. Reboot (needed per snap install instructions) 4. Install at least one snap package that creates a bin directory: sudo snap install hello-world 5. Verify directory presence and context: ls -Z -d /var/lib/snapd/snap/bin 6. Start spamassassin daemon: sudo systemctl start spamassassin 7. Verify selinux AVC alert May 16 09:03:52 <host> audit[1145]: AVC avc: denied { search } for pid=1145 comm="spamd" name="snapd Actual results: An AVC denial. Expected results: No AVC denial. Additional info: Workaround mentioned above is to add: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin to '/etc/sysconfig/spamassassin'
Caught in enforcing mode: ---- type=PROCTITLE msg=audit(10/10/2023 11:22:18.809:398) : proctitle=/usr/bin/perl -T -w /usr/bin/spamd -c -m5 -H --razor-home-dir=/var/lib/razor/ --razor-log-file=sys-syslog type=PATH msg=audit(10/10/2023 11:22:18.809:398) : item=0 name=/var/lib/snapd/snap/bin nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(10/10/2023 11:22:18.809:398) : cwd=/ type=SYSCALL msg=audit(10/10/2023 11:22:18.809:398) : arch=x86_64 syscall=newfstatat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x55649d34c900 a2=0x55649ce174a8 a3=0x0 items=1 ppid=1 pid=4677 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=spamd exe=/usr/bin/perl subj=system_u:system_r:spamd_t:s0 key=(null) type=AVC msg=audit(10/10/2023 11:22:18.809:398) : avc: denied { search } for pid=4677 comm=spamd name=snapd dev="vda2" ino=999985 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:snappy_var_lib_t:s0 tclass=dir permissive=0 ---- Steps to Reproduce: 1) install the snapd package 2) install the spamassassin package 3) start the spamassassin service 4) search for SELinux denials # rpm -qa selinux\* snapd\* spam\* | sort selinux-policy-38.29-1.fc38.noarch selinux-policy-devel-38.29-1.fc38.noarch selinux-policy-doc-38.29-1.fc38.noarch selinux-policy-sandbox-38.29-1.fc38.noarch selinux-policy-targeted-38.29-1.fc38.noarch snapd-2.58.3-1.fc38.x86_64 snapd-selinux-2.58.3-1.fc38.noarch spamassassin-4.0.0-3.fc38.x86_64 #
Caught in permissive mode: ---- type=PROCTITLE msg=audit(10/10/2023 11:33:12.629:442) : proctitle=/usr/bin/perl -T -w /usr/bin/spamd -c -m5 -H --razor-home-dir=/var/lib/razor/ --razor-log-file=sys-syslog type=PATH msg=audit(10/10/2023 11:33:12.629:442) : item=0 name=/var/lib/snapd/snap/bin nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(10/10/2023 11:33:12.629:442) : cwd=/ type=SYSCALL msg=audit(10/10/2023 11:33:12.629:442) : arch=x86_64 syscall=newfstatat success=no exit=ENOENT(No such file or directory) a0=AT_FDCWD a1=0x7fffa8187060 a2=0x7fffa8186fd0 a3=0x0 items=1 ppid=1 pid=5652 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=spamd exe=/usr/bin/perl subj=system_u:system_r:spamd_t:s0 key=(null) type=AVC msg=audit(10/10/2023 11:33:12.629:442) : avc: denied { search } for pid=5652 comm=spamd name=snapd dev="vda2" ino=999985 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:snappy_var_lib_t:s0 tclass=dir permissive=1 ---- It seems that the access to /var/lib/snapd directory is not really necessary because the spamd processes do not complain in enforcing mode.
Test coverage for this BZ exists in a form of PR: * https://src.fedoraproject.org/tests/selinux/pull-request/433 The PR waits for a review.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.