From owner-freebsd-arch Tue Jul 24 12:24:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id E7B4137B409; Tue, 24 Jul 2001 12:24:31 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f6OJOSs111282; Tue, 24 Jul 2001 15:24:28 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: 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> Date: Tue, 24 Jul 2001 15:24:23 -0400 To: Matt Dillon , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Changes to utmp, wtmp & lastlog entries Cc: Garrett Wollman , brian@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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: >:<:> 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-arch" in the body of the message