From owner-freebsd-security Mon Nov 4 14:50:04 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA08864 for security-outgoing; Mon, 4 Nov 1996 14:50:04 -0800 (PST) Received: from offensive.communica.com.au (offensive-eth1.adl.communica.com.au [192.82.222.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA08834 for ; Mon, 4 Nov 1996 14:49:55 -0800 (PST) Received: from communica.com.au (frenzy.communica.com.au [192.82.222.65]) by offensive.communica.com.au (8.7.6/8.7.3) with SMTP id JAA24050; Tue, 5 Nov 1996 09:20:31 +1030 (CST) Received: by communica.com.au (4.1/SMI-4.1) id AA09752; Tue, 5 Nov 96 09:13:46 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9611042243.AA09752@communica.com.au> Subject: Re: chroot() security To: brantk@atlas.com (Brant Katkansky) Date: Tue, 5 Nov 1996 09:13:46 +1030 (CST) Cc: newton@communica.com.au, Don.Lewis@tsc.tdk.com, marcs@znep.com, dev@trifecta.com, freebsd-security@FreeBSD.org In-Reply-To: <199611041845.KAA15255@itchy.atlas.com> from "Brant Katkansky" at Nov 4, 96 10:45:37 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Brant Katkansky wrote: > > Note that I'm not suggesting this as something that should be added to > > FreeBSD per se; Rather, I'm suggesting that users of FreeBSD in security- > > critical environments can benefit from having kernel sources by taking > > the opportunity to "harden" their kernel. > > How 'bout making it a compile-time option? I think some people are missing the point. The kind of "security-conscious" environment I'm talking about is something like a firewall or a very restricted access system. Now, in both of those situations, it is expected that the organization that is running the system has some kind of written (or otherwise) policy to determine how that system is treated. That policy more or less defines exactly how secure that system is going to be by specifying the rights and privileges of the system itself and the users who login to it (if any) One of the things that can be done on that system is to hack the kernel to enforce the policy in software -- That way you have to trust the system a little bit less, because your software enforces your policy for you. Each organization will have their own security policy. We cannot, ahead of time, say, "Yeah, everyone will want this." Thus, putting these hacks in as compile-time options is not appropriate: it'll only ever lead to bloat which very few people (those who agree with your particular policy) will take advantage of. On the other hand, some kind of FAQ might be useful to make sure that people are aware of the potential that the presence of source code provides for them. If that's publicized then people are free to make their own hacks to enforce their own policies. Cheers, - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au