From owner-freebsd-security Sat Sep 18 18:28:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id BAC931510D for ; Sat, 18 Sep 1999 18:28:20 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SVm2-0007ZL-00; Sat, 18 Sep 1999 19:28:15 -0600 Message-ID: <37E43C2C.69F167F9@softweyr.com> Date: Sat, 18 Sep 1999 19:28:12 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Cc: Warner Losh , Brett Glass , Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <4.2.0.58.19990917160519.047cc890@localhost> <199909172208.QAA05554@harmony.village.org> <19990918012538.A1195@grok.localnet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steve wrote: > > I think the boot scripts should be redesigned to do only what is really > necessary pre-securelevel, raise the securelevel ASAP, then pass control > to post-securelevel scripts. Keep the chflags requirements to a > minimum. I sort of plan to do this for my own systems. There are some other holes in startup, too. I'm not sure how much we should discuss in such a public forum, some of them might be better to air as a fait accompli, and some are peculiar to the application I'm looking at. > Really, I have slightly more grandiose plans, mainly allowing remote > sysadmin (that's me) to upload scripts and have them run > pre-securelevel: stick them in a directory, reboot, and have the boot > process run them after verifying PGP signatures (and sequence numbers to > prevent replay attacks). For those times when you just _have_ to fix a > vulnerability involving a schg file but can't get to the console for a > while. This of course conflicts somewhat with my previous paragraph. That's an interesting idea. I think it would be important to disallow such scripts from adding to the signatures, though. > I would be happy to share such a boot process if/when I actually get > around to doing it. I don't think it would be very difficult. That would be great. > As for automating the lock-down procedure, I would suggest a change be > made to the kernel such that it can print warnings when an unprotected > binary or library is used, and also when an unprotected file is opened. > By "unprotected" I mean one that is not schg, OR who's parent > directories are not sufficiently protected to prevent stuff being moved > around. At the start of the boot process enable the warnings and then > disable them after securelevel is raised. If you get any of these > theoretical warnings about a binary or library, fix it. If you get such > warnings on an unprotected file, make sure you know what it's about. A > reasonable flag for these warnings might be kern.securelevel==0 (as in, > "It's not -1 because I really do want to raise the securelevel, but I'm > vulnerable at the moment, so tell me if I do anything risky"). > > Unfortunately I don't know enough about the kernel to make such a > change. An interesting idea. One of the military systems I worked on long ago had a background thread that would continually checksum program memory and fault the processor if it got a checksum mismatch. Each of the binary images were padded with checksum bytes to make the checksum match, and the "unload" routine would restore the "transient program area" to a known pattern. I've often thought it would be a good idea to at least checksum executable files, or perhaps even sign them, and modify the loader so it will refuse to execute any executable (shared library, etc) not properly checksummed or signed. An interesting extension to the signing mechanism would be to require a local as well as vendor signature, so root would have to sign an executable before it can be run on THAT system. This would obviously require multiple local signatures for executables loaded from NFS servers. Does this idea show merit for high-security installations? > BTW, what are these deficiencies people are talking about with > securelevel? When properly configured it seems to me to be well suited > to stopping an intruder from going invisible with trojaned ls, ps, > syslogd, tripwire, etc. No more, no less. Or am I missing something? It's not always available (i.e. early in booting) and it doesn't tell you about denied attempts. The lack of logging is the biggest failure from the standpoint of a security manager. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message