Date: Tue, 24 Jul 2001 15:24:23 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Matt Dillon <dillon@earth.backplane.com>, arch@FreeBSD.ORG Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, brian@FreeBSD.ORG Subject: Changes to utmp, wtmp & lastlog entries Message-ID: <p05101010b7835b988e5f@[128.113.24.47]> In-Reply-To: <200107231707.f6NH7wU18016@earth.backplane.com> References: <000f01c11315$094851e0$420d640a@HELL> <200107230354.f6N3stj13517@earth.backplane.com> <200107231538.f6NFcZl81468@khavrinen.lcs.mit.edu> <200107231557.f6NFvQb17025@earth.backplane.com> <200107231649.f6NGnq982448@khavrinen.lcs.mit.edu> <200107231707.f6NH7wU18016@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a spin-off of the thread in -security about:
bin/22595: telnetd tricked into using arbitrary peer ip
I figured we might as well bring it up in -arch at this point. The
question is what (if any) changes should we make to the way entries
are made to utmp, wtmp, and lastlog. If you look at that PR, there
are some security implications wrt how those entries are currently
handled, and thus it would be a good idea to do something about them.
I'm quoting some of the recent background here, but you'd want to
check that PR (and all the followup entries to it) for full details:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22595
At 10:07 AM -0700 7/23/01, Matt Dillon wrote:
>Garrett Wollman wrote:
>:<<On Mon, 23 Jul 2001, Matt Dillon said:
>:> Garrett Wollman wrote:
>:> : SVR4 has an API. This API is standardized as a part of
>:> : the Austin Group process.
>:
>:> Fine.. then if you want to get all the third party program
>:> authors to use a magic API, be my guest.
>:
>: If they run on Solaris -- which most of them do -- then they already
>: do. Nice try, Matt, but far off the mark.
>:
>:-GAWollman
>
> Really.. Lets see. wu-ftpd... nope. proftpd... nope. Want me
> to continue?
Still... If there *is* an API which would be common to both Solaris
and FreeBSD, then it should be much easier to get third-party program
authors to accept changes to use that API.
As for the best change to make, let me suggest that we basically
follow both Matt's and Garrett's recommendations (which were made
in other messages in the thread).
Let's increase the size of UT_HOSTSIZE to at least 56, so the field
can always hold the complete IP address (even for IPv6) in the field,
but let's encourage programs to use whatever the standardized API is
to make these entries. There will be a bit of a transition-hit when
the size of the field is changed, where anything that usees or sets
these records will need to be recompiled. Maybe we should do this
change as part of 5.0, and not MFC it.
If you read all the entries in the PR, Brian noted that OpenBSD has
already changed UT_HOSTSIZE to be 256. I might go for something
larger than 56 (such as 64, just to be a computer geek who always
picks powers of 2...), but I don't think freebsd needs to go all
the way to 256.
I don't feel too strongly about the actual solution decided upon,
but I did think it was about time to have this topic explicitly
mentioned in freebsd-arch, so we can figure out what is best to do
and then do whatever that is.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101010b7835b988e5f>