MIT Krb5 + SELinux

[Jerome Walter]

On Tue, Apr 13, 2004 at 03:01:44PM -0400, Jeffrey Hutzelman wrote:
> 
> 
> On Tuesday, April 13, 2004 03:00:40 +0200 Jerome Walter 
> <walter+kerberos at efrei.fr> wrote:
> 
> >By the way, a common constant on the programs is that most want access
> >do urandom devices, but do not require it really. I guess, that to
> >create tickets, kdc do need access to the device, otherwise the work
> >could be altered.
> 
> The session keys used to protect communications between clients and servers 
> in Kerberos-authentication applications are generated by the KDC.  In fact, 
> the acronym KDC stands for "Key Distribution Center", and these session 
> keys are the keys being distributed.  The KDC generates a new session key 
> every time it issues a ticket, and in order to generate good keys, it must 
> have access to a decent source of entropy.
[snip]

I know the application need access to random data. In fact, my 2 main
purpose where 
1. Does the apps need access to any other device than urandom and 
tcp/udp/socket files ?
2. What restriction could i safely make on the different parts of the
kerberos process without breaking it or possibly open a breach in
granularity offered by SELinux.

For now, i opened the urandom, so the point is not to know if i should
do it, but to know if there is any other randomness(or other) source
that could not appear at first, and make the cryptography of kerberos
being weaker...

I have another point determining which files in /etc/krb5kdc (for debian
and gentoo at least) for the different parts of server need.
I think kdc do not need writing on keytab files, isn't it ?
kadmin should need writing to these files, but we can fairly safely
remove any writing access to any configuration files for both, is that
true ?
Do clients need writing access to any file ? I think tickets are stored
into the memory (and i hope so), so except for the access to files
needed by the application they replace, plus access to krb5.conf, it
could be fairly safe. 

I look forward some details, but i am in the way of finishing debugging
the most visible denials and errors...

Best regards,


Jerome
-- 
-+--   Jerome Walter - 	EFREI p2004		          ----+-
       Mail *is* private