Jeffrey Altman <jaltman@columbia.edu> writes:
>> > > > There is a desire to allow credentials to be forwarded after the
>> > > > connection is established. In this situation you really have no
>> > > > choice but to tamper with the credentials cache as root.
>>
>> 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.
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.
To prevent this, whoever writes the creds *must* know who the user is.
One possibility is to have telnetd pass the new creds somehow to the
existing login process:
> 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.
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.
Marc
