>>>>> "Greg" == Greg A Woods <woods@weird.com> 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:
	 open(2)	  
	 socket(2)
	 write(2)	[different types of files]
	 mknod(2)
	 set{ug}id(2)
	 passing of FD's in UNIX domain sockets
	 revoke(2)
	 listen(2)

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

  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[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [