Bug 760224 - When using STARTTLS, the confined user need access to urandom_device_t
Summary: When using STARTTLS, the confined user need access to urandom_device_t
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 16
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-05 16:37 UTC by Göran Uddeborg
Modified: 2011-12-30 01:01 UTC (History)
1 user (show)

Fixed In Version: selinux-policy-3.10.0-69.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-30 01:01:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Göran Uddeborg 2011-12-05 16:37:31 UTC
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};

Comment 1 Daniel Walsh 2011-12-05 21:00:55 UTC
Miroslav lets add dev_read_urand(user_mail_domain)


To f16 and RHEL6.

Comment 2 Miroslav Grepl 2011-12-06 08:52:48 UTC
Added to selinux-policy-3.10.0-65.fc16

Comment 3 Fedora Update System 2011-12-25 22:41:46 UTC
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

Comment 4 Fedora Update System 2011-12-26 19:18:52 UTC
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).

Comment 5 Fedora Update System 2011-12-30 01:01:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.