[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hard links to a directory in a chroot environment

On Wed, 24 Sep 1997 11:43:53 +0200 joost witteveen 
(joost@rulcmc.leidenuniv.nl) wrote:

> [..]
> > Hard linked directories are bad, it would taker longer than that to explain.
> That's apity, cause I've been wanting to know why they are
> bad for a long time. Do you have any reference where I can
> search for an answer on that one?

I have no reference, but I'll try to explain :-)
When one does a mkdir():
  1. A directory special file is created, and an inode is allocated.
  2. A `.' entry is created in this new directory, pointing to the 
     inode allocated in 1.
  3. A `..' entry is created, pointing to the parent's inode.
All this is now performed atomically in the kernel through (2)mkdir, 
but there was a time when mkdir was performing these three steps in 
user space.

When a rmdir() is done (assuming the directory is empty):
  1. Entries . and .. are removed.
  2. The directory inode is unlinked from the parent's directory 

Having a hard link to a directory gives a first problem:
Say you do:
	mkdir /usr/dir1
	link /usr/dir1 /usr/local/dir1 (hard links /usr/dir1 to 
Then if you do cd /usr/local/dir1/.., you'll get to /usr.
And there's no way for a program to detect that (the same thing can 
happen with symlinks, but one can read the symlinks contents).

Second problem: you can create loops in the filesystem, eg:
	mkdir /usr/dir1
	link /usr/dir1 /usr/dir1/loop
Now start a find in /usr you can always wait for it to end. 
/usr/dir1/loop is equal to /usr/dir1 (inode-wise).

Third problem: rmdir() doesn't work on a directory which is hard 
linked. Removing the . and .. entries will cause mayhem for the 
remaining links.

Fourth problem: fsck doesn't work anymore and cannot fix some kind of 
problems anymore. Fsck operation relies on the fact that the 
directory tree, well err, is a tree. Allowing hard links between 
directories makes the directory structure an oriented graph.

For all these reasons (and probably others I've never heard of), 
directory hard linking is discouraged. Most other unices forbid it 
too, or at least makes this feature a root-only privilege.

And also, you can achieve the same effect 99% of the time with a 
symbolic link. The remaining 1% can be nailed down through a nfs loop 
mount (this 1% generally involves chroot()ed environments).

> > For maximum security in chrooted environments:
> >   o don't mount /proc in the chrooted tree
> [..]
> >   o don't have devices in the chrooted tree
> Why are these? I can understand that they will cause havoc when
> a user in a chrooted becomes root, but if they do, they can create
> the devices/mounts files anyway. So, why are they suddenly a problem
> in chrooted environments?

About /proc:
/proc contains information about all the processes in the computer.
Which means that a process running a a chrooted environment can acces 
to the working directory of any process running with the same uid 
outside of the chroot() dir through /proc/<uid>/cwd. Funny ?
Assuming that you're root, and you're got a chrooted invironement in 
/chroot, and proc is mounted on /chroot/proc, try:
	cd /chroot
	chroot /chroot /bin/bash
	cd /proc/1/cwd
Hop, you're back in the real / (cwd of init).
Note that you don't have to be root to exploit this.

About devices:
Well, devices are common to the whole machine, which mean that if 
you've got a word-writable /dev/hda, someone in the chrooted 
environement can still trash your computer.
However, if the permissions in the chrooted /dev are very 
conservative *and* there is no setuid executable in the chrooted 
tree, it should be reasonably safe.

Oh, and there's one more thing which is also shared between the 
normal and chrooted environment: sockets, and IPC stuff.
IPC stuff (shared memory, semaphores, etc...) is not a problem, 
unless there's a cooperating process outside the chrooted 
Sockets are more annoying: any process can bind to unprovileged 
sockets, and any process can create a socket. Which means that 
someone in the chrooted environment can send crap to your syslog 
socket for example...

> (I'm not questioning your wisdom, I'm just curious).

My wisdom is sometimes questionable :-)


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: