[ 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
repaired behaviour!

> 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
to implement?)

> 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
again!

> 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      <gwoodsacm.org>     <woodsrobohack.ca>
Planix, Inc. <woodsplanix.com>;   Secrets of the Weird <woodsweird.com>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]