[1106] in linux-net channel archive
Re: login, telnetd and utmp
daemon@ATHENA.MIT.EDU (Craig Metz)
Sat Sep 16 00:29:56 1995
To: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
cc: linux-net@vger.rutgers.edu
In-reply-to: Your message of "Wed, 13 Sep 1995 17:48:00 +0200."
<199509131548.RAA07098@i17linuxb.ists.pwr.wroc.pl>
Date: Fri, 15 Sep 1995 16:23:15 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
In message <199509131548.RAA07098@i17linuxb.ists.pwr.wroc.pl>, Marek Michalkiew
icz writes:
>after looking at various login sources which all claim to support Linux
>(util-linux, shadow, logdaemon)
Count NRL OPIE 2.03 as one, too.
>I noticed that we have no standard way
>of utmp handling. The problem is that we have a SysV-style utmp but
>we use BSD-style networking programs like telnetd and rlogind.
This is a bigger problem than you can imagine, because nobody really
has a standard way to handle the utmp. I'd say that about a fifth or a sixth
of the work that I've done for NRL OPIE 2.x has been utmp brain-damage
related.
>The version of login from util-linux creates an utmp entry if there is
>none, the version from the shadow suite requires a valid utmp entry
>when run without any flags (like -h from telnetd), the version from
>logdaemon-4.9 always insists on a valid utmp entry (and works with the
>supplied telnetd which creates one, but not with the standard Linux
>telnetd from NetKit-B).
The first two behaviors are corred. Someone should talk to Wietse
about logdaemon if what you say is correct, because not all init's will
create utmp entries, and so that behavior will lose badly on systems like
that with real ttys.
>In addition, login from util-linux does a hostname lookup to fill in
>the ut_addr field with the IP address corresponding to the name given
>after the -h option.
Uhh. No. No! This makes the ut_addr totally unreliable. Consider:
You do a reverse DNS lookup in telnetd, then you do a forward DNS lookup in
login. login CANNOT determine the real IP address because it doesn't have
access to the socket (proc filesystem, kmem trolling, and other fun aside).
It is trivial to create a case where ut_addr != the remote IP address. This
is really not good.
> In a typical setup with tcp wrappers, this means
>four DNS lookups:
>
>- tcp wrapper does two lookups (IP -> name and then name -> IP to verify
> that the two IP addresses match)
This will make the above attack more difficult, but not impossible
(now it's a race).
>- telnetd does getpeername() and one IP -> name lookup for login -h
>- login does a name -> IP lookup to fill in ut_addr
>
>Of course, every DNS lookup takes some time, especially if the nameserver
>is down... I am proposing the following:
Paul Vixie is promising a resolver-daemon to handle more state to
solve this problem.
>- modify telnetd to create an utmp entry with all known fields filled in
> (including ut_line: why use slow ttyname() if telnetd already knows
> the tty name?) and add a built-in tcp wrapper (using libwrap.a from
> tcp-wrappers-7.2)
telnetd is already too big. I don't think bloating it more is the
best idea.
>- modify login to require a valid utmp entry for the current process
> (like SysV login does) and don't fill in the ut_addr field
This seems reasonable to me.
Unfortunately, requiring either of these two behaviors to interact
with each other is not a good idea. Many people will run other telnet daemons
(like the KerberosV one) and/or other login programs (like the OPIE one).
Breaking these people needlessly is not a good thing.
-Craig
