Date: Tue, 5 Nov 1996 01:15:12 +0100 (MET) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: newton@communica.com.au (Mark Newton) Cc: freebsd-security@FreeBSD.org Subject: Re: chroot() security Message-ID: <199611050017.BAA17765@ocean.campus.luth.se> In-Reply-To: <9611042243.AA09752@communica.com.au> from Mark Newton at "Nov 5, 96 09:13:46 am"
next in thread | previous in thread | raw e-mail | index | archive | help
According to Mark Newton: > 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. It's not what I'm talking about. I'm talking about giving people an opportunity to make their system a bit more secure, if it's possible with their setup. > 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. "If you can't write a UNIX on your own, you shouldn't use our's either"? I think we should go the other way, making it easier to use FreeBSD. "We can not make FreeBSD perfect for all occations, so why even try?" is not a good way to go, I think. Add a code to make chroot more secure. Make it a compile time option. Then people can choose to use it or not, as it will inevidably bring SOME problem with it, no matter how it's done. The bloat is very small, and only a source-bloat. Not a kernel bloat. An FAQ entry? Yes, ofcourse! Describe how you can use the compile time option, and what problems it brings, and what it solves. Add a hint to the handbook, where you describe what's done why, and suggest alternations depending on need. That way people can change it if they want, with a guiding hand. Step by step instructions, basically. Hacking stuff in the kernel is much worse then crunching a userspace program into exactly what you want it to. Things you do can affect stuff you didn't even know existed, etc. I for one would be very careful about trying to add something like this safer chroot patch. And I wouldn't know were to start. With the option in I can go in and change my config file and try the default. If it's not exactly what I want, then I can look through the files for code that has ifdef for that option, and I can read the FAQ entry, and maybe dare go in and do a small change to that, in it self, small patch (you (?) said it was, at least). Hmm.... Do you see my point? /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611050017.BAA17765>