Quoth [EMAIL PROTECTED] (Tomas Maly): [... re credentials in /tmp ] | Any way, I was wondering if it was thought of how to | secure this hole. Would it be possible to make a | ticket cache file valid only for a particular process | group, perhaps? Is there any current ways to tighten | security? I would like to not force removing root | access from these untrusted users (such as for their | Linux PCs).
If you're giving root access to someone, they're trusted! I guess you mean that they're not worthy of the trust you place in them? Something's unclear here. Here are a couple more questions for you: - Do these credentials have any value at all? I mean, do you use them, does anyone use them? It sounds like they're the by-product of password validation. It might take some work in login.krb5, but in theory those credentials are optional. - Following the password validation assumption, are those passwords in the clear on the network? - Can your users actually use Kerberos? Can they have Kerberos telnet or ssh on their desktop? If you do the Kerberos single login thing, and then use your credentials to "log in" to a remote host, you don't go through that password validation step and wouldn't have credentials there (unless you deliberately forward them.) This is really a _more_ secure way to deal with trust issues - compared to say ssh or SSL with passwords, where you expose your password to the remote host. | Also, I've noticed that the login.krb5 program creates | a pseudo-random filename for the cache (such as | /tmp/krb5cc_XYZPDQ). Why is this? You could have several sessions concurrently on the same host. This way you don't lose your credentials from one session when another one starts or exits (they're deleted on exit.) Donn Cave, [EMAIL PROTECTED] ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos