Description of problem: A little while after configuring my mail server to use TLS recently, I started to get AVC:s about the user_mail_t domain not being allowed to read the urandom_device_t. After a bit of investigation, I realized this happens when a user who is user_u rather than unconfined_u tries to use sendmail to send a mail. For example, by using the plain old "mail" command. The mail still arrives, although with a delay. The initial delivery to the local server fails, with TLS error messages in the log. So instead the letter is queued. And when the regular sendmail queue runner gets around to empty the queue, it has all the permissions needed, and the letter does get delivered. I made myself a policy module to allow this. It turns out that the "getattr" and "open" permissions are needed, in addition to "read". (I'm slightly surprised "read" was the first to show up. I would have guessed the process needed to open before it read. But I'm sure there is some explanation for that.) There are two booleans that would have allowed this, authlogin_nsswitch_use_ldap and global_ssp. But they are really meant for other purposes, and would allow more than necessary. So I chose to do a dedicated module instead. I'm not sure if you want to integrate this into the default policy, or if you would consider it a corner case that each admin has to take care of. I'm submitting this bugzilla "for consideration". Version-Release number of selected component (if applicable): selinux-policy-targeted-3.10.0-55.fc16.noarch How reproducible: Every time Steps to Reproduce: 1. Log in as a user_u user. 2. Send a mail using /bin/mail Actual results: An AVC message like this: type=SYSCALL msg=audit(1322665205.313:21022): arch=c000003e syscall=2 success=no exit=-13 a0=7fecfce7d52f a1=900 a2=7fecfd0c10a0 a3=7fffa944d8d0 items=0 ppid=21556 pid=21557 auid=505 uid=505 gid=505 euid=505 suid=505 fsuid=505 egid=51 sgid=51 fsgid=51 tty=(none) ses=3185 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:user_r:user_mail_t:s0 key=(null) type=AVC msg=audit(1322665205.313:21022): avc: denied { read } for pid=21557 comm="sendmail" name="urandom" dev=devtmpfs ino=1048 scontext=user_u:user_r:user_mail_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file followed by a similar attempt to open random_device_t instead. (This, I believe is an attempt by sendmail to recover from the failure to use urandom_device_t. When I allowed the former, I no longer got the latter.) type=SYSCALL msg=audit(1322665205.313:21023): arch=c000003e syscall=2 success=no exit=-13 a0=7fecfce7d53c a1=900 a2=7fecfd0c10a0 a3=7fffa944d8d0 items=0 ppid=21556 pid=21557 auid=505 uid=505 gid=505 euid=505 suid=505 fsuid=505 egid=51 sgid=51 fsgid=51 tty=(none) ses=3185 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:user_r:user_mail_t:s0 key=(null) type=AVC msg=audit(1322665205.313:21023): avc: denied { read } for pid=21557 comm="sendmail" name="random" dev=devtmpfs ino=1047 scontext=user_u:user_r:user_mail_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file In the maillog, error messages like these turned up: Nov 30 16:00:04 mimmi sendmail[21557]: pAUF03LL021557: from=david, size=110709, class=0, nrcpts=1, msgid=<20111130150003.GA21220>, relay=david@localhost Nov 30 16:00:05 mimmi sendmail[21557]: STARTTLS=client, error: connect failed=-1, SSL_error=5, errno=0, retry=-1 Nov 30 16:00:05 mimmi sendmail[21557]: ruleset=tls_server, arg1=SOFTWARE, relay=[127.0.0.1], reject=403 4.7.0 TLS handshake. Nov 30 16:00:05 mimmi sendmail[21557]: pAUF03LL021557: to=mangled-for-spambots, ctladdr=david (505/505), delay=00:00:02, xdelay=00:00:00, mailer=relay, pri=140709, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake. Nov 30 16:00:05 mimmi sendmail[21558]: STARTTLS=server, error: accept failed=0, SSL_error=5, errno=0, retry=-1, relay=localhost [127.0.0.1] Nov 30 16:00:05 mimmi sendmail[21558]: pAUF05qO021558: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Nov 30 16:00:14 mimmi sendmail[21574]: pAUF0EWr021574: from=<SELinux_Troubleshoot@mimmi>, size=3675, class=0, nrcpts=1, msgid=<201111301500.pAUF0EWr021574.se>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] Expected results: The mail should be delivered as normal. Additional info: This is the rule I have in my module. After installing it, I haven't seen any further denials. allow user_mail_t urandom_device_t:chr_file {getattr open read};
Miroslav lets add dev_read_urand(user_mail_domain) To f16 and RHEL6.
Added to selinux-policy-3.10.0-65.fc16
selinux-policy-3.10.0-69.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-69.fc16
Package selinux-policy-3.10.0-69.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-69.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-17464/selinux-policy-3.10.0-69.fc16 then log in and leave karma (feedback).
selinux-policy-3.10.0-69.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.