[SOLVED] Msmtp access to /etc/pki flagged by selinux

[vladms]

I use msmtp as mta, to send emails from cron scripts. This works and I receive the emails as expected. I have selinux activated and I noticed an audit denial for a write to /etc/pki/ca-trust/source which I find surprising.

Anybody has any idea what could be the reason? Or what else I could do to investigate?

See below for some info, /etc is mounted on dev/sda4.

$ ausearch --start today -m avc -i
----
type=PROCTITLE msg=audit(06/05/2025 02:33:58.738:28787) : proctitle=/usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f xxxxx@xxxxx.xxx
type=SYSCALL msg=audit(06/05/2025 02:33:58.738:28787) : arch=x86_64 syscall=access success=no exit=EACCES(Permission denied) a0=0x55e452e70d20 a1=W_OK a2=0x0 a3=0x0 items=0 ppid=2911802 pid=2918405 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=sendmail exe=/usr/bin/msmtp subj=system_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(06/05/2025 02:33:58.738:28787) : avc: denied { write } for pid=2918405 comm=sendmail name=source dev=“sda4” ino=8388788 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0

$ find /etc -inum 8388788
/etc/pki/ca-trust/source

$ rpm -qi msmtp
Name : msmtp
Version : 1.8.22
Release : 1.el9
…

[gerry666uk]

msmtp is from epel, not from official Rocky repos.

A mail transfer agent wants to write to a certificate store location, and selinux thinks it’s not right.

msmtp does support TLS, but you’d expect it to be reading, unless you’ve told it to generate certificates or something.

msmtp might have it’s own debug logs, worth checking.

[vladms]

I have researched a bit more and my initial interpretation “an audit denial for a write to /etc/pki/ca-trust/” is incorrect.

Based on NB ObjectClassesPermissions - SELinux Wiki , to quote:

If a process calls access() or faccessat() and SELinux denies their request there will be a check for a dontaudit rule on the audit_access permission. If there is a dontaudit rule on audit_access an AVC event will not be written. If there is no dontaudit rule an AVC event will be written for the permissions requested (read, write, or exec).

So in fact SELinux reports that the process tried to check if it can write, to which the answer was “no” (EACCESS) but this gets in the AVC (which is the cache of permissions granted/denied) as a “denied write”

Ok, so I was curious who (and potentially why) would check the access. So I fired up gdb and breakpoint on access and run msmtp and got the following:

#0 0x00007ffff78fd6d0 in access () from /lib64/libc.so.6
#1 0x00007ffff68b1c6d in check_directory.lto_priv () from /usr/lib64/pkcs11/p11-kit-trust.so
#2 0x00007ffff68a54b1 in sys_C_GetTokenInfo () from /usr/lib64/pkcs11/p11-kit-trust.so
#3 0x00007ffff7ca9a42 in _pkcs11_traverse_tokens () from /lib64/libgnutls.so.30
#4 0x00007ffff7cacc25 in gnutls_pkcs11_obj_list_import_url4 () from /lib64/libgnutls.so.30
#5 0x00007ffff7cacd7a in gnutls_pkcs11_obj_list_import_url3 () from /lib64/libgnutls.so.30
#6 0x00007ffff7d0c9ba in gnutls_x509_trust_list_add_trust_file () from /lib64/libgnutls.so.30
#7 0x00007ffff7c7b971 in gnutls_x509_trust_list_add_system_trust () from /lib64/libgnutls.so.30
#8 0x000055555556b29c in mtls_init ()
#9 0x0000555555564a96 in msmtp_sendmail ()
#10 0x0000555555559e18 in main ()

So seems the “culprit” is the library p11-kit-trust which seems to be used for many things related to certificates (use and creation), with one of the function references in the stack trace being p11-kit/trust/module.c at cd761134869d1350fb7b7d477947cf83a33133de · p11-glue/p11-kit · GitHub which determines if something is writable.

As a conclusion, nothing related specifically to Rocky/msmtp/selinux (but not obvious when you don’t know), I would have been great if SELinux would have been more clear even for non experts, I mean “write” and “check is writable” are quite different thing to put under the same message.

[gerry666uk]

Yes, I can see it says ‘syscall=access’ now, which I’d missed when I read the original error message.

But I’d say the first thing to check is the code in ‘mtls_init ()’, why is it calling “add trust file”? Implies it wants to “add” something.

If the problem is in gnutls, I’d expect to see hundreds of users reporting the same error.

[vladms]

gnutls_x509_trust_list_add_trust_file(3) - Linux manual page - no experience with gnutls but this seems to add the existing files to the “in-memory” trust list, so nothing strange there from my point of view.

There are several reasons why it might not be reported more often: a) there is no error, as in fact it does not want to write, hence it will not fail. b) msmtp (not standard) is not used in a SELinux environment (not used by everybody either). c) people notice the fact that this is only checking the access and do not report it (if I would have notice that I would have not posted either).