Do you have raw AVC msgs?

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

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

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

seems like an ssh bug if it is opening it for write...

Possible...how to track it down best?

Petr, do you have any idea why sshd might be opening /dev/urandom for write?

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?

If I am interpreting the a1 argument correctly, 0x41 is 0101 which maps to O_WRONLY|O_CREAT. That just seems wrong.

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).

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.

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?

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.

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?