Date: Wed, 20 Dec 2000 17:41:29 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Kris Kennaway <kris@FreeBSD.ORG> Cc: Mark Zielinski <markz@2cactus.com>, cjclark@alum.mit.edu, freebsd-security@FreeBSD.ORG Subject: Re: Read-Only Filesystems Message-ID: <20001220174129.F19572@fw.wintelcom.net> In-Reply-To: <20001220174056.C22288@citusc.usc.edu>; from kris@FreeBSD.ORG on Wed, Dec 20, 2000 at 05:40:56PM -0800 References: <20001219114936.A23819@rfx-64-6-211-149.users.reflexco> <20001219120953.S19572@fw.wintelcom.net> <20001219211642.D13474@citusc.usc.edu> <3A40BED3.1070909@2cactus.com> <20001220174056.C22288@citusc.usc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
* Kris Kennaway <kris@FreeBSD.ORG> [001220 17:39] wrote: > On Wed, Dec 20, 2000 at 02:14:43PM +0000, Mark Zielinski wrote: > > This is a attack that we fixed in SecureBSD by not allowing > > filesystems to be un-mounted and re-mounted back in May of 1999. > > We added security checks to the mount() and unmount() system calls > > based upon a MIB called securebsd.options.mount which could be > > turned on or off depending upon your securelevel setting. > > The argument is that securelevel is fundamentally flawed and fairly > useless as a security feature, unless you treat every system reboot > (expected or not) as a potential compromise. Actually, securelevel as a all-covering blanket would work better if people implemented fixes for it like a solution for the mount problem described here. Securelevel is hard to implement, but hard to mess up unlike ACLs which are both hard to implement and hard to deploy. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20001220174129.F19572>