Subject: Re: i386 IO access and chroot()
To: NetBSD Security Technical Discussion List <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 07/18/2001 00:04:22
[ 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.
Are you actually suggesting that there should be a way out of a chroot
jail if you happen to have root privileges?!?!?!?
Please tell me I'm wrong as if not I must vehemently disagree!
The introduction of fchdir() broke chroot() [more than it was already
broken in concept]. The 1.131 change to sys/kern/vfs_calls.c finally
fixes that bug (among other things).
[[ Oh, if I had a dime for every time some systems programmer introduced
some fancy new feature without understanding the consequences.... :-) ]]
> I know that BSD 4.3 (BSDi 1.x and BSDi 2.0), and Solaris 1, as well as
> stock AT&T SVR4.2 had the original behaviour. It was useful in some esoteric
> situations. Of course, those systems did not have fchdir(2) as I recall.
What original behaviour are you talking about? The original behaviour
of chroot() without fchdir() is (hopefully) the same as the current now
> Again, I just want to have jail(2) or some such, and I think that many
> applications would be overjoyed with that.
I'm still hoping someone smarter than myself will do a careful analysis
to show what useful differences, if any, there are between FreeBSD's
jail(2) and a normal chroot jail when the system is at a securelevel>=2....
Or do you want to eat your cake and still have it too -- eg. run at
securelevel < 2 and still have a superuser-safe chroot?
What disadvantages to existing applications using chroot() would there
be if chroot() implied all that setting securelevel>=2 implies, but only
for the processes within the chroot jail? (and how hard would that be
> 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.
I'm not sure you gain anything there, and you might even open more holes
> And, given the ability to pass FDs in Unix domain sockets, that would
> permit some kind of client/server executable authorization system possible.
It might, but that might not be all it permits!
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>