RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 841329 - SELinux targeted policy prevents confined users from using gpgsm with gpg-agent
Summary: SELinux targeted policy prevents confined users from using gpgsm with gpg-agent
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.2
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-18 17:27 UTC by Benjamin Kreuter
Modified: 2013-02-21 08:25 UTC (History)
2 users (show)

Fixed In Version: selinux-policy-3.7.19-159.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:25:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0314 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2013-02-20 20:35:01 UTC

Description Benjamin Kreuter 2012-07-18 17:27:36 UTC 
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 20:20:07 UTC 
Fixed in Rawhide.
Comment 3 Milos Malik 2012-07-19 09:40:18 UTC 
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 09:52:30 UTC 
# 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 15:43:12 UTC 
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 16:09:23 UTC 
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 17:42:23 UTC 
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 07:47:54 UTC 
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 08:25:40 UTC 
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.