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;
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