Bug 1076979 - Missing urandom_device_t write access slows down Kerberos-based SSO SSH logins
Summary: Missing urandom_device_t write access slows down Kerberos-based SSO SSH logins
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.5
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-16 22:37 UTC by Robert Scheck
Modified: 2014-03-22 10:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-22 10:14:22 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Robert Scheck 2014-03-16 22:37:55 UTC
Description of problem:
After my SELinux talk I got the feedback that a SELinux rule is required to
speed up Kerberos-based SSO SSH logins. The workaround was/is the following
SELinux rule:

  allow sshd_t urandom_device_t:chr_file write;

Without this rule any SSH login (Kerberos-based SSO) takes like a minute or
similar - the wild guess is that if /dev/urandom can not be accessed it will
take the random data from something else but that likely needs more time?

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.7.19-231.el6.noarch

Actual results:
Very slow Kerberos-based SSO SSH login.

Expected results:
Normal speed during Kerberos-based SSO SSH login.

Additional info:
Right now I do not have an AVC message with me, so please let me know if you
need one or more details etc. Thanks!

Comment 2 Miroslav Grepl 2014-03-17 13:24:36 UTC
Do you have raw AVC msgs?

Comment 3 Robert Scheck 2014-03-18 10:00:46 UTC
type=AVC msg=audit(1393323902.572:1067): avc:  denied  { write } for pid=20668 comm="sshd" name="urandom" dev=devtmpfs ino=3793 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file

Comment 5 Steve Grubb 2014-03-18 15:33:53 UTC
I can understand a read, but not a write. Is there more to the AVC like the syscall record so that we can see hat is really happening? To get it, you can add a rule to /etc/audit/audit.rules for -w /etc/shadow -p w. I know the rule is for shadow, but enabling audit rules by inserting just 1 rule should produce more information. You should be able to extract the complete avc like this:

ausearch -m avc -o urandom_device_t -i

Comment 6 Robert Scheck 2014-03-18 17:51:08 UTC
Running "ausearch -m avc -o urandom_device_t -i" brings:

type=SYSCALL msg=audit(07.03.2014 12:35:53.365:8221) : arch=x86_64 syscall=open success=no exit=-13(Keine Berechtigung) a0=7fffa85559d0 a1=41 a2=180 a3=4113bb30c1b2fbab items=0 ppid=1408 pid=22457 auid=user uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1336 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(07.03.2014 12:35:53.365:8221) : avc:  denied  { write } for  pid=22457 comm=sshd name=urandom dev=devtmpfs ino=3793 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file

Comment 7 Eric Paris 2014-03-18 18:00:19 UTC
seems like an ssh bug if it is opening it for write...

Comment 8 Robert Scheck 2014-03-18 19:19:55 UTC
Possible...how to track it down best?

Comment 9 Steve Grubb 2014-03-18 20:33:25 UTC
Petr, do you have any idea why sshd might be opening /dev/urandom for write?

Comment 10 Petr Lautrbach 2014-03-19 07:51:30 UTC
sshd calls RAND_load_file(random, randlen) when the SSH_USE_STRONG_RNG environment variable is set to non-zero. So this is probably not the case.

I would guess it's an issue of libgssapi_krb5 or something related to the pam configuration.

Is it possible to provide more informations about the specific configuration?

Comment 11 Steve Grubb 2014-03-19 13:55:38 UTC
If I am interpreting the a1 argument correctly, 0x41 is 0101 which maps to O_WRONLY|O_CREAT. That just seems wrong.

Comment 12 Robert Scheck 2014-03-20 16:04:39 UTC
Ah! It turned out that Heimdal Kerberos rather MIT Kerberos is in use.

When looking now to heimdal-1.5.2/lib/hcrypto/rand-unix.c, there is
function _hc_unix_device_fd() with a device list which is called by
function unix_seed() that calls _hc_unix_device_fd(O_WRONLY, NULL);.

Unfortunately my C knowledge is too bad to figure out if that write
is really that one from the AVC and if it is correct or not. The next
question is (if the O_WRONLY is correct) if the SELinux policy can be
adapted anyway even if RHEL doesn't officially support Heimdal (just
correct me if I am wrong about the support status).

Comment 13 Steve Grubb 2014-03-20 19:07:15 UTC
Its actually pointless for the software to do that. The seeding its doing does not increase the entropy. Urandom does not actually need any seeding once boot has completed. The write could be allowed. Its more or less harmless. But there's really no point in doing it. If it tried an ioctl to credit the entropy pool, I'd be more concerned.

Comment 14 Robert Scheck 2014-03-20 19:36:01 UTC
If it is more or less harmless, I do not really get why the login takes much
longer if the write access is forbidden rather allowed. Trying to write to a
device file where one is not allowed to write...should not take longer?

Comment 15 Steve Grubb 2014-03-20 19:54:09 UTC
It looks like it walks a list of devices trying each one until it can finally seed one of them. I'd really suggest a patch like this:

--- heimdal-1.5.2.orig/lib/hcrypto/rand-unix.c
+++ heimdal-1.5.2/lib/hcrypto/rand-unix.c
@@ -73,18 +73,6 @@ _hc_unix_device_fd(int flags, const char
 static void
 unix_seed(const void *indata, int size)
 {
-    int fd;
-
-    if (size <= 0)
-       return;
-
-    fd = _hc_unix_device_fd(O_WRONLY, NULL);
-    if (fd < 0)
-       return;
-
-    write(fd, indata, size);
-    close(fd);
-
 }


Urandom and random on Linux do not need seeding.

Comment 16 Robert Scheck 2014-03-21 08:56:18 UTC
Steve, thank you for your time and suggestion. I was in touch with upstream, so
http://repo.or.cz/w/heimdal.git/commit/8a4cf0dd12a43c5f0da52ec9325a1d9e2420260a
is the result there now. I guess this should be now closed as "notabug" or so?


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