[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hurdish applications for persistence
From: |
Alfred M. Szmidt |
Subject: |
Re: Hurdish applications for persistence |
Date: |
Tue, 11 Oct 2005 12:29:35 +0200 (CEST) |
But let's take a closer look. Take for example a "firmlink"
translator, which is a bit of a cross between a soft link and a
hard link. Furthermore, consider a user running a shell in a
chrooted environment. The user is malicious and wants to escape
the chroot. If the user installs an active firmlink to "/"
somewhere in its chrooted filesystem tree, this fails: The firmlink
translator will see the same chrooted root directory as the user
themselves. But what if the user installs a passive firmlink
translator and then accesses it (for example via an ls -l)? Then
the filesystem will do the startup _and give the firmlink
translator a port to the real, unchrooted directory port_. The
user can escape the chroot following the firmlink. This is an
obvious security exploit.
A obvious security exploit in the chroot() implementation (or really,
file_reparent) and not in how passive translators work. If you want a
secure chroot enviroment (right now atleast) then you should run a
sub-hurd. Where this isn't possible (atleast, I have never been able
to break out of a sub-hurd, and I have tried). So instead of using
broken UNIXoid ideas like chroot, it would make far more sense to
implement a light-weight sub-hurd which can be used like chroot.
Now the question is, can this be fixed? Can for example the
filesystem realize that the user installing the passive translator
is chrooted, and thus store the chroot information in the passive
translator setting?
There is no reason to do that.
- Hurdish applications for persistence, Marcus Brinkmann, 2005/10/10
- Re: Hurdish applications for persistence, Ludovic Courtès, 2005/10/11
- Re: Hurdish applications for persistence,
Alfred M. Szmidt <=
- Re: Hurdish applications for persistence, Bas Wijnen, 2005/10/11
- Re: Hurdish applications for persistence, ams, 2005/10/11
- Re: Hurdish applications for persistence, ness, 2005/10/11
- Re: Hurdish applications for persistence, ams, 2005/10/11
- Re: Hurdish applications for persistence, ness, 2005/10/11
- Re: Hurdish applications for persistence, ams, 2005/10/11
- Re: Hurdish applications for persistence, ness, 2005/10/11
- Re: Hurdish applications for persistence, ams, 2005/10/11
- Re: Hurdish applications for persistence, ness, 2005/10/11
- Re: Hurdish applications for persistence, ams, 2005/10/11