From owner-freebsd-chat Mon Nov 18 09:16:57 1996 Return-Path: owner-chat Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA28505 for chat-outgoing; Mon, 18 Nov 1996 09:16:57 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA28486; Mon, 18 Nov 1996 09:16:52 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id JAA15646; Mon, 18 Nov 1996 09:16:36 -0800 (PST) From: Don Lewis Message-Id: <199611181716.JAA15646@salsa.gv.ssi1.com> Date: Mon, 18 Nov 1996 09:16:35 -0800 In-Reply-To: Bill Fenner "Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2)." (Nov 18, 8:42am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Bill Fenner , Don Lewis Subject: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2). Cc: chat@freebsd.org, security@freebsd.org Sender: owner-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 18, 8:42am, Bill Fenner wrote: } Subject: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2). } In message <199611180918.BAA15007@salsa.gv.ssi1.com>you write: } >I don't need a compiler, and I don't want to make } >it any easier than necessary for some cracker d00d to compile his r00t } >kit. } } If you want to save space, that's fine, but don't delude yourself by thinking } that your cracker d00d can't just go find someone on IRC with a FreeBSD box } who will send him binaries. I'm not counting on gaining much security that way, but my philosophy is to remove everything that isn't absolutely needed. What isn't present can't be used against me. I do consider the importation of any files to be a security breach. I just thought of a totally wicked way of guarding against imported binaries, though. Just randomize the syscall numbers when building the kernal and userland binaries. For best effect, the userland binaries should be statically linked and the shared libraries removed. As long as the kernel can withstand crashme, it should be fine ;-) Too bad it looks like such a pain to do this :-( Another possibility would be to digitally sign all the binaries and hack the kernel to only run binaries with the proper signature. --- Truck