Date: Sun, 20 Jun 1999 00:49:48 -0700 (PDT) From: "Brian W. Buchanan" <brian@CSUA.Berkeley.EDU> To: Nicholas Brawn <ncb@zip.com.au> Cc: freebsd-security@FreeBSD.ORG Subject: Re: proposed secure-level 4 patch Message-ID: <Pine.BSF.4.05.9906200024390.70357-100000@smarter.than.nu> In-Reply-To: <Pine.LNX.4.05.9906201710460.17277-100000@zipper.zip.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Jun 1999, Nicholas Brawn wrote: > On Sat, 19 Jun 1999, Brian W. Buchanan wrote: > > > Anyway, this all boils down to a matter of choice. If you value being > > able to restart daemons without rebooting, then don't use this level of > > protection. > > Here's an idea i'll toss into the ring. What about runtime integrity > checks. If there were some way of guaranteeing that a program being > executed has the correct checksum prior to processing execve()? > > I'm not advocating this line of approach, but it may be one option to > consider. Using MD5 checksums in-kernel would certainly be an effective countermeasure against the mount_union ruse I described last night, as well as against starting new daemons on privileged ports. I don't think it would be very useful for most installations, but this could be a very good thing for systems with a fixed set of binaries and that the sysadmin doesn't mind downing to do even very minor software upgrades. The more I think about securelevels and related topics, the more I think we should be putting our efforts into making sure that attackers don't break rootin the first place, rather than into clever attempts to limit damage once a compromise has occured. The whole "root is god" design principle is at odds with these efforts, and I'm resonably confident that there are still undiscovered holes of varying size in the implementation. In dealing with and planning for the event of incidents, the attitude that must be taken is that no matter what the configuration, once root has been compromised, all bets are off. -- Brian Buchanan brian@CSUA.Berkeley.EDU -------------------------------------------------------------------------- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9906200024390.70357-100000>