On Tue, Aug 15, 2000 at 02:00:17PM -0400, Marc Horowitz wrote: > Jeffrey Altman <jaltman@columbia.edu> writes: > >> I'm not sure you understand what I am referring to. The user logs in > >> with telnetd and 10 hours later the user's credentials expire. The > >> user does not want to log in again to the remote host. The user gets > >> new credentials locally (and in the case of Win2000 the operating > >> system does this for you automatically) and wants the new credentials > >> forwarded to the host. There is no /bin/login or /bin/su process > >> being executed by telnetd. That already happened when the initial > >> credentials are received. > >> > >> What is required is for the telnetd process to update the user's > >> credentials cache after the user is already logged in. > > I still don't see why this requires modifying the ccache as root. As > Bill Sommerfeld pointed out, you could setreuid() to the user, or fork > off a helper process which runs as the user. Right, but telnetd also needs to know who the user if this was not specified in the protocol as login (PAM_KRB5) would presumably name the cache file after the user's UID. Of course, if the username is not specified in the telnet exchange, but authentication is done in the telnet exchange using Kerberos, then you have another issue: /bin/login has to know the principal as which the remote client authenticated so /bin/login can authorize the remote client to the requested account. It would be safer to always require that the username be specified in the telnet protocol when performing Kerberos authentication. > One problem you need to address is the user renaming the ccache. This > is pretty common around MIT, as people have aliases for managing > different ccaches, and want them to have easier names to find than > /tmp/krb5cc_p3566 (which is what I just got when doing a krb5 telnet > forwarding tickets). My tickets now have a different name. If > telnetd tries to write to the file as root, then either it won't be > there, or some other user may have maliciously moved their own ccache > in place, and telnetd will happily write my fresh credentials into > their credentials cache. I'm not sure how you update creds in this > case at all, but certainly there should be zero chance of accidentally > giving the creds to another user. Geez, I rename my cache files too sometimes. :) > To prevent this, whoever writes the creds *must* know who the user is. And the user's cache filename. Alternatively, if the file is never replaced, just edited in place, then telnetd can keep it open and pass the open file descriptor and the file name to /bin/login, where PAM_KRB5 can do any additional processing. > One possibility is to have telnetd pass the new creds somehow to the > existing login process: Yup. > > ps -f -p $$ -p 3870 -p 3566 > UID PID PPID C STIME TTY TIME CMD > root 3566 390 0 13:36:38 ? 0:01 telnetd -a cred > marc 3892 3870 0 13:37:16 pts/96 0:00 -betatcsh > root 3870 3566 0 13:37:13 pts/96 0:00 login -h marble-madness.toybox.cambridge.ma.us -p -f marc > > login certainly knows who the user should be, and can write the new > creds out safely, or not at all. > > Finally, to whomever suggested passing the creds in the environment, > do "ps auxeww" on your favorite BSD machine and reconsider. The > environment of all processes is trivially visible to all users. If > you put the creds into the environment, there's always going to be a > window where a malicious user can steal them, and that's unacceptable, > too. That was me. Forget that suggestion. > What I'm learning from this thread is that the telnetd/login division > of labor may have made sense in 1981, but it doesn't make sense any > more today. With modern security infrastructures, the process which > implements the network protocol and the client which manages the > host's user login process cannot be completely separate. Setting up a > bidirectional communications channel between telnetd and login may be > sufficient, but I suspect combining them would be easier. I'm beginning to agree. Early in this thread I suggested absorbing some of /bin/logn's functionality into telnetd. Perhaps all of /bin/login should be replaced by telnetd. > Marc Nico --
