Date: Sun, 20 Jun 1999 22:37:57 +0200 From: Eivind Eklund <eivind@FreeBSD.ORG> To: "Brian W. Buchanan" <brian@CSUA.Berkeley.EDU> Cc: FreeBSD-security Mailing List <freebsd-security@FreeBSD.ORG> Subject: Re: proposed secure-level 4 patch Message-ID: <19990620223757.K63035@bitbox.follo.net> In-Reply-To: <Pine.BSF.4.05.9906201312120.70357-100000@smarter.than.nu>; from Brian W. Buchanan on Sun, Jun 20, 1999 at 01:19:31PM -0700 References: <19990620180356.J63035@bitbox.follo.net> <Pine.BSF.4.05.9906201312120.70357-100000@smarter.than.nu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 20, 1999 at 01:19:31PM -0700, Brian W. Buchanan wrote: > On Sun, 20 Jun 1999, Eivind Eklund wrote: > > I think using securelevel 4 for this is a bad idea. I believe the > > right thing to do with securelevels is to start splitting them into a > > set of different sysctls, where each individual feature can be turned > > off. It is convenient to have a set of sysctls you can use to "turn > > off everything" (like securelevel does today). > > > > However, to apply a "full securelevel" to a box is difficult; the > > ability to throw away single capabilities could be very useful. > > I considered suggesting this last night, then realized that applying only > the effect added by securelevel 3 or the proposed level 4 would be > ineffective, as it's easily circumvented through loading a custom kernel > module, writing to /dev/kmem, etc. Blocking the binding of low ports > would be ineffective without restrictions on changing IPFW rules, as IIRC > IPFW rules can be used to redirect packets from one port to another. You may be thinking of the 'divert' option to IPFW. This can be used with a TCP/IP stack in userland, if you also send out raw packets. The same can be done with BPF, so if you want to block this capability, you also need to block BPF use. > For what we have now and for the proposed securelevel 4, I'd say that the > current system makes sense. If we did start to add security features that > are orthogonal to the present ones, however, I'd agree that they should > be separate sysctl knobs. Securelevel 2 would still be pretty much > mandatory for enforcing any other restrictions on root, though. Securelevel 3 and (proposed) 4 are pretty much orthogonal on securelevel 2, at least. They only need restrictions on kmem and LKMs to be effective. As it is, the attempts at changing the meaning of securelevel (which was, in my reading, intended to allow a compromised system to come up without further exploits being possible due to a rebooot) means that a bunch of orthogonal stuff is being put into higher securelevels. This introduce extra compatibility cruft we'll have to handle when we switch to a sensible scheme. I won't go so far as to say that the introduction of securelevel 4 is a regression (it is nice functionality when you want to truly secure a box), but it would be much better if it came after having made "securelevel" a set of orthogonal switches. Eivind. 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?19990620223757.K63035>