atom feed13 messages in org.freebsd.freebsd-archRe: Changes to utmp, wtmp & lastlog e...
FromSent OnAttachments
Garance A DrosihnJul 24, 2001 12:24 pm 
Brian SomersJul 24, 2001 3:58 pm 
Garrett WollmanJul 24, 2001 4:06 pm 
Brian SomersJul 24, 2001 4:18 pm 
Matt DillonJul 24, 2001 4:35 pm 
Dima DorfmanJul 25, 2001 12:53 am 
Peter C. LaiJul 25, 2001 12:34 pm 
Jeroen MassarJul 25, 2001 3:14 pm 
Peter C. LaiJul 25, 2001 3:28 pm 
Jeroen MassarJul 25, 2001 3:37 pm 
Brian SomersJul 25, 2001 6:59 pm 
Cy Schubert - ITSD Open Systems GroupJul 26, 2001 11:49 am 
Matthew N. DoddJul 30, 2001 9:19 am 
Subject:Re: Changes to utmp, wtmp & lastlog entries
From:Peter C. Lai (sir@cowbert.2y.net)
Date:Jul 25, 2001 12:34:52 pm
List:org.freebsd.freebsd-arch

Furthermore, there is a problem with the way that lastlog records logoffs via HUP. If someone ssh's in, and then HUPs the terminal without using "logout" or "exit" (e.g. by closing the window) then lastlog records that they are still logged in. This makes login accounting difficult. Now should I submit this as a separate PR about about lastlog or should this be tacked on to changes for lastlog/*tmp?

Garance A Drosihn writes:

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.

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message