From owner-freebsd-hackers Mon Dec 18 09:09:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07370 for hackers-outgoing; Mon, 18 Dec 1995 09:09:19 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA07360 for ; Mon, 18 Dec 1995 09:09:16 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id KAA23836; Mon, 18 Dec 1995 10:11:34 -0700 Date: Mon, 18 Dec 1995 10:11:34 -0700 From: Nate Williams Message-Id: <199512181711.KAA23836@rocky.sri.MT.net> To: "Frank ten Wolde" Cc: Nate Williams , hackers@FreeBSD.ORG Subject: Re: Order of rules in ip_fw chain In-Reply-To: <9512181801.ZM8519@pwood1.pinewood.nl> References: <9512151302.ZM27077@pwood1.pinewood.nl> <199512151611.JAA16380@rocky.sri.MT.net> <9512151720.ZM309@pwood1.pinewood.nl> <199512151639.JAA16535@rocky.sri.MT.net> <9512181801.ZM8519@pwood1.pinewood.nl> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I think we disagree here, or our needs differ greatly :-) I still think > it's better for safety that *if* my Bastion host is compromised (someone > evil becomes root) they still cannot flush the fw chain. Agreed. My statement was made to say that I think we need to have more security levels than the current version, so we can still have a secure system and *still* allow modifications of the ipfw chain. It doesn't have to be an all or nothing affair. > I accept > bringing down the host to single user mode for adding/deleting rules -- > after *careful* consideration of the new rules. I can't do that w/out wiping out my internet connection, and I'd rather not do that for the sake of other people in my company. :) > Should we make the save-fw-chain a configuration option in the kernel? > Perhaps we must add a new level to securelevel to allow for secure fw > chains *on top of* the very secure mode (e.g., securelevel 3). Maybe > we need to re-define securelevel to be a bit-field to enable secure mode > for independent sub-systems in the kernel? Would this be too large a > deviation from the original 4.4BSD definition? I think having multiple secure levels is a good thing, but I don't have time to think about how it should best be done. :( Nate