svn commit: r224462 - stable/8/usr.sbin/jail

[Jason Hellenthal]

On Wed, Jul 27, 2011 at 11:08:31PM -0400, Ben Kaduk wrote:
> On Wed, Jul 27, 2011 at 10:19 PM, Jason Hellenthal <jhell at dataix.net> wrote:
> >
> >
> > On Wed, Jul 27, 2011 at 01:56:52AM +0000, Glen Barber wrote:
> >> Author: gjb (doc committer)
> >> Date: Wed Jul 27 01:56:52 2011
> >> New Revision: 224462
> >> URL: http://svn.freebsd.org/changeset/base/224462
> >>
> >> Log:
> >>   MFC 224286:
> >>
> >>   Document the potential for jail escape.
> >>
> >>   PR:         142341
> >>
> >> Modified:
> >>   stable/8/usr.sbin/jail/jail.8
> >> Directory Properties:
> >>   stable/8/usr.sbin/jail/   (props changed)
> >>
> >> Modified: stable/8/usr.sbin/jail/jail.8
> >> ==============================================================================
> >> --- stable/8/usr.sbin/jail/jail.8     Tue Jul 26 20:51:58 2011        (r224461)
> >> +++ stable/8/usr.sbin/jail/jail.8     Wed Jul 27 01:56:52 2011        (r224462)
> >> @@ -34,7 +34,7 @@
> >>  .\"
> >>  .\" $FreeBSD$
> >>  .\"
> >> -.Dd January 17, 2010
> >> +.Dd July 23, 2011
> >>  .Dt JAIL 8
> >>  .Os
> >>  .Sh NAME
> >> @@ -913,3 +913,10 @@ Currently, the simplest answer is to min
> >>  offered on the host, possibly limiting it to services offered from
> >>  .Xr inetd 8
> >>  which is easily configurable.
> >> +.Sh NOTES
> >> +Great care should be taken when managing directories visible within the jail.
> >> +For example, if a jailed process has its current working directory set to a
> >> +directory that is moved out of the jail's chroot, then the process may gain
> >> +access to the file space outside of the jail.
> >> +It is recommended that directories always be copied, rather than moved, out
> >> +of a jail.
> >
> > How is either one of these different ?
> >
> > All mv(1) is doing is a cp(1) & rm(1). In either case the filehandle is
> 
> This is not always true when the source and destination live on the
> same filesystem.  See rename(2).
> Via VOP_RENAME, individual filesystems can override this behavior if
> needed (e.g. for AFS where permissions are per-directory, so a
> cross-directory copy would return EXDEV).
> 

Ok so in the least words... be careful of poor administration
techniques that is trying to be explained here. The only real example I
could think of that relates to the example above would be in the case of
a hardlink that rests on the same filesystem.

Anyway just a nit-pick it just seems trying to explain these things in
example throughout a manual page can lead a user in the direction of
thought that everything has been explained or that is all the examples
and seems would be better off in a security aware section of a handbook
rather than mudding up the manual page.

> 
> > still broken and a process is not going to just get up and move with it.
> > On the other side though if you copied a pipe or socket or something
> > similiar for example into a jail then it might make whatever is outside
> > available to the jailed environment.
> >
> > Is there something I am misunderstanding about this ? has the way cp(1),
> > rm(1) & mv(1) been changed recently ? or is this wording a little off ?
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-stable/attachments/20110728/e8a0a253/attachment.pgp