From owner-freebsd-security Sun Nov 3 11:05:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA15338 for security-outgoing; Sun, 3 Nov 1996 11:05:01 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA15318 for ; Sun, 3 Nov 1996 11:04:42 -0800 (PST) Received: (from narvi@localhost) by haldjas.folklore.ee (8.7.5/8.6.12) id VAA11072; Sun, 3 Nov 1996 21:05:56 +0200 (EET) Date: Sun, 3 Nov 1996 21:05:55 +0200 (EET) From: Narvi To: Mikael Karpberg cc: Mark Newton , freebsd-security@FreeBSD.org Subject: Re: chroot() security In-Reply-To: <199611030511.GAA14093@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 3 Nov 1996, Mikael Karpberg wrote: > According to Mark Newton: > [...] > > 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. Those who make the attempt > > will find that once their security policy has been codified in written form, > > translating that written form to source code is surprisingly easy > > (interdependencies and subtle interrelationships notwithstanding - Be > > careful!). The suggestion given above, for example, can be implemented > > with just a few lines of C. > > (Gives me some ideas. Thought I'd share them.) > > Why not? Make an option for it in the LINT file, and just #ifdef it? > > option SAFER_CHROOT #Warning, this might break some executables. > > Something like it, at least? Yes. Something like that would be nice (at least as an oppourturity. > Or maybe make some sysclt or something where you can set it on a per > process basis? proc_no_chroot - don't allow the process and any of it's children chroot proc_no_setuid - don't allow the process and any of it's children call setuid - breaks all setuid programs which "give up" their privileges (login, etc.) proc_no_setuidp - don't allow the process and it's children exec setuid programs (in case there are some) - breaks ping, login etc. Would allow you to make login accounts with different levels of restrictions. Whetever any of these would be worth it is another question. Sander > And/Or have a safer_chroot() or no_setuid_chroot() lib call that lets you > add a FreeBSD specific (unless this is copied to other OSes) patch in ports, > etc to make some programs more secure? > > I have no idea how braindamaged any of these ideas are, and for what reason, > but I thought I'd see the reactions on this. > > /Mikael >