Subject: Re: i386 IO access and chroot()
To: NetBSD Security Technical Discussion List <firstname.lastname@example.org>
From: Michael Richardson <email@example.com>
Date: 07/21/2001 20:35:08
>>>>> "Greg" == Greg A Woods <firstname.lastname@example.org> writes:
Greg> [ On Tuesday, July 17, 2001 at 21:23:16 (-0400), Michael Richardson wrote: ]
>> Subject: Re: i386 IO access and chroot()
>> I would suggest:
>> 1) introduce jail(2)
>> 2) introduce chroot43(2), original behaviour.
Greg> Are you actually suggesting that there should be a way out of a chroot
Greg> jail if you happen to have root privileges?!?!?!?
Greg> Please tell me I'm wrong as if not I must vehemently disagree!
Let me rephrase your sentence:
I am suggesting that there should be a way out of a chroot(2) call if the
caller wishes it.
Please note that I did not use the term "jail" --- there are plenty of
useful things that one can do with chroot(2) that do not involve security.
Frequently, I've wanted to do things like:
mount -o union / /my/new/root
chroot /my/new/root /bin/sh
This lets me build test environments for various things.
This is why I suggest that those that wish security features, probably want
a bunch of things other than just chroot(2).
>> Again, I just want to have jail(2) or some such, and I think that many
>> applications would be overjoyed with that.
Greg> I'm still hoping someone smarter than myself will do a careful analysis
Greg> to show what useful differences, if any, there are between FreeBSD's
Greg> jail(2) and a normal chroot jail when the system is at a securelevel>=2....
Greg> Or do you want to eat your cake and still have it too -- eg. run at
Greg> securelevel < 2 and still have a superuser-safe chroot?
No, I want jail(2) to include a bunch of other things, only one of which is
the chroot(2) equivalent option.
Greg> What disadvantages to existing applications using chroot() would there
Greg> be if chroot() implied all that setting securelevel>=2 implies, but only
Greg> for the processes within the chroot jail? (and how hard would that be
Greg> to implement?)
That's one thing.
But, I'd rather that we set a bit for each thing that securelevel>=2
implies, and toggle that. Some of these things might also include:
write(2) [different types of files]
passing of FD's in UNIX domain sockets
>> The other thing that I wanted to be able to do was exec a fd. That way,
>> I could have one process create a jail, open another executable, give up
>> root, chroot, etc. and then exec the new program, without having to have
>> even the binary of the program in the chroot area.
Greg> I'm not sure you gain anything there, and you might even open more holes
I might, but it depends upon what I'm trying to do, doesn't it.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] email@example.com http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [