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
entry.
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
/usr/local/dir1)
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
environement.
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 :-)
Phil.
--
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: