Subject: chroot vulnerability through misuse?

From: John Olp <[email-masked]>
Date: Wed, 19 Aug 1998 18:24:58 -0700

Help!  I want to setup a directory structure that looks similar to the
following (except that there will be an untold number of foo/bar users):

/usr/ftp/
     |
     +- foo (foo's guest root)
     |   |
     |   +- regular-guest-structure (/etc, /bin, .rhosts, .forward, etc.)
     |   |
     |   +- foo's-stuff
     |   |
     |   +- common-stuff
     |
     +- bar (bar's guest root)
     |   |
     |   +- regular-guest-structure (/etc, /bin, .rhosts, .forward, etc.)
     |   |
     |   +- bar's-stuff
     |   |
     |   +- common-stuff
     |
     +- common-stuff

Because of the large number of users and because the contents of
common-stuff change often enough, we would like to administrate
common-stuff singularly outside each guest user's space
(/usr/ftp/common-stuff) and link the directory into each users space.  In
this case, a symlink will not work since the chrooted guest users are
prevented from traversing backward in the tree beyond their new root.

However, creating a hard link does the job fine except the following
behavior occurs (at least on FreeBSD):  When foo changes his current
directory to common-stuff's parent directory (ie, foo changes to
/common-stuff/..), instead of foo finding himself at his root again, he
finds himself in the original common-stuff directory and is able to walk
the entire file system.

Is this supposed to happen?  If so, I'm surprised I haven't seen a single
warning about this.  If it isn't supposed to, is there an easier way of
accomplishing my goal than hacking kernel and/or chroot code to fix it?

TIA,

John Olp

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 20 Aug 1998 07:41:36 -0400 (EDT)

> accomplishing my goal than hacking kernel and/or chroot code to fix it?

Check your setup to make sure you're actually doing the chroot you think
you are.  It looks like you're not.  The guest howto referenced in the FAQ
will help.  If you're really chroot'd, check your version of FreeBSD,
upgrade to the latest stable version, and if it still occurs, talk to the
developers.

----

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: bruce draper <[email-masked]>
Date: Thu, 20 Aug 1998 09:11:21 -0500 (CDT)

it's an artifact of you hardlinking the common-stuff directory into each
user's chrooted area: common-stuff/.. is, in fact, always the .. of the
original common-stuff directory.  that's why directories are supposed to
only have a single parent; you must have been root to break the rules
and make those links to begin with :-)

you need to make a real common-stuff dir for each user and then hardlink
the files from the template common-stuff dir to each user common-stuff dir
or use something like a loopback mount from the real common-stuff dir to
each user's common-stuff dir.

bruce

-- 
bruce draper		| "just because we make it is no reason for me to
			|  refrain from observing the emperor has no clothes"
[email-masked]	|                      -- me

---

From: joe turbulencia <[email-masked]>
Date: Thu, 20 Aug 1998 12:02:13 -0400 (EDT)

> prevented from traversing backward in the tree beyond their new root.

	symlinks will work if they are referenced with respect to the
	chroot.  only chroot'ed accounts could use them, though. 
	conversely, non-chroot'ed accounts will have to either use a
	directory alias or a symlink that references common-stuff in its
	complete path.  i usually hide most things from the users, but i
	do give them the directory aliases in their .message file.  they
	just cd to the directory aliases to navigate their way in the 
	server.

> finds himself in the original common-stuff directory and is able to walk

	he could, but he sees nothing if he doesn't have read
	permission.  he could be given read permission only to
	stuff he's supposed to see.  maybe i'm not making sense 
	here, but that may be because i don't entirely understand
	your description above.  my apologies.

---

From: John Olp <[email-masked]>
Date: Thu, 20 Aug 1998 13:42:16 -0700

>and make those links to begin with :-)

It's true I (ab)used root priveledge to change the linkage on a directory.
I hoped that would have been my easy solution.  I understand the nature of
how a directory can have only one parent, so It's a no-brainer to explain
why traversing up the tree works under normal use of the file system.  But
what I'm still wondering, is if a chrooted process is supposed to be
restricted from traversing through a "backdoor" created when linkage is
broken.  Using my previous example, the directory pointed to by
common-stuff/.. is of course /usr/ftp.  But /usr/ftp doesn't exist within
foo's chrooted environment.  I hoped a user would get a "restricted",
"access denied", or some other general failure when trying to [cd ..] from
common-stuff.  I figured if a user was in there and needed out, they could
just do [cd /].  What I didn't count on was a user being allowed outside
his chrroted space.

>each user's common-stuff dir.

Too many hardlinks to manage, so I'll probably try the loopback mounts.
Another list member pointed out the fact that if the real common-stuff
directory's parent doesn't "permit" the user to use it, then maybe they'll
be blocked that way.  I'll try that too.

-JO

---

From: Bill Campbell <[email-masked]>
Date: Thu, 20 Aug 1998 18:54:20 -0700

On Thu, Aug 20, 1998 at 12:02:13PM -0400, joe turbulencia wrote:
....
>	complete path.  ....

Given a bit of indirection, the symlinks in a chroot'ed environment can
also be accessed identically by normal users.  All I have to do to make
/pub work from normal logins is ``ln -s ~ftp/pub /pub''.

Bill
--
INTERNET:   [email-masked]  Bill Campbell; Celestial Systems, Inc.
UUCP:               camco!bill  PO Box 820; 6641 E. Mercer Way
FAX:            (206) 232-9186  Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/

``Now if there is one thing that we do worse than any other nation, it is
try and manage somebody else's affairs.''
    Will Rogers