Bug 841329
| Summary: | SELinux targeted policy prevents confined users from using gpgsm with gpg-agent | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Benjamin Kreuter <ben.kreuter> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | dwalsh, mmalik |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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 08:25:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Fixed in Rawhide. 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? # 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 # 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. 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? No, if it needs the access it needs the access, this seems like a definite case where it should access /dev/random.
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
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 |
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;