Bill Studenmund <wrstuden@netbsd.org> writes:

> On Tue, Mar 08, 2005 at 05:22:53PM +0100, Rhialto wrote:
> > 
> > With all these new system calls there are now so many more places where
> > this check needs to be added... I was thinking that it would perhaps be
> > getting more efficient to do all this checking for fd-s outside the
> > chroot area at the time the chroot is done. That is, change the strategy
> > from "check when used" to "check when created".
> 
> The reason we do it this way is to avoid future vulnerabilities. You're 
> describing, in effect, a trusted perimeter. Once inside, an fd is ok.
> 
> The problem is that if there ever is a way to get an fd into the chroot 
> area, the chrooted program can get out; there's no more checking.

Just to satisfy my curiosity:

1. Any fd's open when the chroot is performed. (Could easily be
   flagged at chroot time.)
2. rename() of directories inside the chroot to the outside. (worse)
   (collaborator on the outside "needed".)
3. The oh-so-magic way of passing an open fd via a socket.
   (I have no idea of how it's actually performed. Perhaps I should
   check ssh...) (As easy as 1.)

Any others?


> The overly-aggressive checking we do now ensures that no such issue can 
> arise.
> 
> > That would include the unp_externalize() case when fd-s are passed
> > in via a socket, and when a chroot() variant is done, but I don't think
> > any other place. The check in sys_chdir() could in theory be removed.
> 
> As above, we really want to keep things, "Check when used."

I will.

        Steinar