|Garance A Drosihn||Jul 24, 2001 12:24 pm|
|Brian Somers||Jul 24, 2001 3:58 pm|
|Garrett Wollman||Jul 24, 2001 4:06 pm|
|Brian Somers||Jul 24, 2001 4:18 pm|
|Matt Dillon||Jul 24, 2001 4:35 pm|
|Dima Dorfman||Jul 25, 2001 12:53 am|
|Peter C. Lai||Jul 25, 2001 12:34 pm|
|Jeroen Massar||Jul 25, 2001 3:14 pm|
|Peter C. Lai||Jul 25, 2001 3:28 pm|
|Jeroen Massar||Jul 25, 2001 3:37 pm|
|Brian Somers||Jul 25, 2001 6:59 pm|
|Cy Schubert - ITSD Open Systems Group||Jul 26, 2001 11:49 am|
|Matthew N. Dodd||Jul 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|
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:
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
----------- Peter C. Lai University of Connecticut Dept. of Residential Life | Programmer Dept. of Molecular and Cell Biology | Undergraduate Research Assistant/Honors Program http://cowbert.2y.net/
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message