Bug 841329 - SELinux targeted policy prevents confined users from using gpgsm with gpg-agent
SELinux targeted policy prevents confined users from using gpgsm with gpg-agent
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.2
All Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-18 13:27 EDT by Benjamin Kreuter
Modified: 2013-02-21 03:25 EST (History)
2 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-159.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 03:25:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Benjamin Kreuter 2012-07-18 13:27:36 EDT
Description of problem:

SELinux targeted policy prevents confined users from decrypting S/MIME email, by preventing gpg-agent from reading /dev/random; this affects at least claws-mail using the smime plugin.  The following AVC message is produced:

type=AVC msg=audit(1342630674.755:107): avc:  denied  { read } for  pid=2083 comm="gpg-agent" name="random" dev=devtmpfs ino=3763 scontext=staff_u:staff_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file


Version-Release number of selected component (if applicable):

claws-mail 3.8.0-1.el6.pl1
claws-mail-plugins-smime 3.8.0-1.el6.pl1
selinux-policy-targeted 3.7.19-155.el6_3
gnupg2 2.0.14-4.el6
gnupg2-smime 2.0.14-4.el6

How reproducible:
Very

Steps to Reproduce:
1. Created a confined user (staff_u) with imported s/mime keys for gpgsm and gpg-agent running as a daemon
2. Run claws-mail as that user, using the smime plugin
3. Open an encrypted email message (S/MIME, not PGP)
  
Actual results:

Message does not decrypt; AVC denial is reported by sealert

Expected results:

Decrypted message

Additional info:
This is occuring on ScientificLinux 6.2, with EPEL enabled.  The packages mentioned ago should be clones of packages in RHEL6.2, but I do not have a system available to test that.  Additionally, the S/MIME key was imported before the user was confined; while I did relabel the filesystem after confining the user, there may still be some inconsistency that could conceivably cause this behavior.

This bug can be fixed by using audit2allow; the resulting policy module should do the following:

allow gpg_agent_t random_device_t:chr_file read;
Comment 2 Daniel Walsh 2012-07-18 16:20:07 EDT
Fixed in Rawhide.
Comment 3 Milos Malik 2012-07-19 05:40:18 EDT
Thank you for reporting this bug. It reminded me to write an automated test which will find inconsistencies among selinux-policy rules that allow access to random_device_t and urandom_device_t contexts:

AFAIK there are 4 types of SELinux domains:
1) the domain is allowed to access both /dev/random and /dev/urandom
2) the domain is not allowed to access /dev/random nor /dev/urandom
3) the domain is allowed to access /dev/random but it is not allowed to access /dev/urandom
4) the domain is allowed to access /dev/urandom but it is not allowed to access /dev/random

Question for developers:
Is it really necessary from SELinux point of view to differentiate between /dev/random and /dev/urandom?
Comment 4 Milos Malik 2012-07-19 05:52:30 EDT
# rpm -qa selinux-policy\*
selinux-policy-mls-3.7.19-155.el6_3.noarch
selinux-policy-doc-3.7.19-155.el6_3.noarch
selinux-policy-3.7.19-155.el6_3.noarch
selinux-policy-minimum-3.7.19-155.el6_3.noarch
selinux-policy-targeted-3.7.19-155.el6_3.noarch
# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
# sesearch --allow | grep " random_device_t" | wc -l
193
# sesearch --allow | grep "urandom_device_t" | wc -l
454
#
Comment 5 Daniel Walsh 2012-07-19 11:43:12 EDT
I guess we would ask on the security list.  Obviously someone at some point decided that access to /dev/urandom is less risky then /dev/random, so they labeled them differently.  And as you see we allow more then twice as many domains to access /dev/urandom.  If the security team decided that they were equivalent rick, I would have no problem adjusting the policy.
Comment 6 Benjamin Kreuter 2012-07-19 12:09:23 EDT
I am not an expert, but it might be to prevent applications from draining the entropy pool e.g. as part of a denial of service attack.  For multi-user systems this might be important; for my laptop I am not terribly worried.  Would it make sense to create a boolean for this?
Comment 7 Daniel Walsh 2012-07-19 13:42:23 EDT
No, if it needs the access it needs the access, this seems like a definite case where it should access /dev/random.
Comment 8 Miroslav Grepl 2012-08-08 03:47:54 EDT
type=AVC msg=audit(1342630674.755:107): avc:  denied  { read } for  pid=2083 comm="gpg-agent" name="random" dev=devtmpfs ino=3763 scontext=staff_u:staff_r:gpg_agent_t:s0-s0:c0.c1023 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file

Fixed in selinux-policy-3.7.19-159.el6
Comment 12 errata-xmlrpc 2013-02-21 03:25:40 EST
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, and where to find the updated
files, follow the link below.

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

http://rhn.redhat.com/errata/RHBA-2013-0314.html

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