Breaking out of a chroot on the Hurd is trivial: just use a passive
translator. A passive translator will inherit the namespace of the
file system which started it, not the process which set it. Thus, a
chroot'ed user need only run:
settrans -c root /hurd/firmlink /
Neighbor Hurds won't suffer from this problem.
I don't have any ideas offhand of how this could be fixed.
Thanks,
Neal
Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Breaking out of a chroot on the Hurd is trivial: just use a passive
translator.

I couldn't reproduce this

Script started on Wed May 18 06:19:32 2005
ams@Catoblepas:~$ cd chroot
ams@Catoblepas:~/chroot$ ids
effective uids: 1002(ams)
effective gids: 1002(ams)
available uids: 1002(ams) 1002(ams)
available gids: 1002(ams) 1002(ams) 1002(ams)
ams@Catoblepas:~/chroot$ chroot .
bash-3.00$ showtrans root
bash-3.00$ settrans -p root /hurd/firmlink /
bash-3.00$ showtrans root
/hurd/firmlink /
bash-3.00$ cd /
bash-3.00$ ls
bin hurd lib root
bash-3.00$ exit
exit
ams@Catoblepas:~/chroot$ exit
exit

Script done on Wed May 18 06:20:58 2005

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

"Neal H. Walfield" <neal (AT) walfield (DOT) orgwrites:

Breaking out of a chroot on the Hurd is trivial: just use a passive
translator. A passive translator will inherit the namespace of the
file system which started it, not the process which set it. Thus, a
chroot'ed user need only run:

settrans -c root /hurd/firmlink /

Neighbor Hurds won't suffer from this problem.

I don't have any ideas offhand of how this could be fixed.

It's easier than that; you can just directly ask the proc server for
the global system root.

The Hurd doesn't have Unixy chroots by design, but you can make a
subhurd which you can't break out of. That's the correct way to solve
the problems that Unix solves with chroot.

Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

At Wed, 18 May 2005 00:23:11 -0400,
Alfred M. Szmidt wrote:

Breaking out of a chroot on the Hurd is trivial: just use a passive
translator.

I couldn't reproduce this

Script started on Wed May 18 06:19:32 2005
ams@Catoblepas:~$ cd chroot
ams@Catoblepas:~/chroot$ ids
effective uids: 1002(ams)
effective gids: 1002(ams)
available uids: 1002(ams) 1002(ams)
available gids: 1002(ams) 1002(ams) 1002(ams)
ams@Catoblepas:~/chroot$ chroot .
bash-3.00$ showtrans root
bash-3.00$ settrans -p root /hurd/firmlink /
bash-3.00$ showtrans root
/hurd/firmlink /
bash-3.00$ cd /

This bit is wrong. root now gives access to the real root (or at
least the root in the file system's name space).

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

I don't have any ideas offhand of how this could be fixed.

It's easier than that; you can just directly ask the proc server for
the global system root.

can proxy the proc server.

The Hurd doesn't have Unixy chroots by design, but you can make a
subhurd which you can't break out of. That's the correct way to solve
the problems that Unix solves with chroot.

I'm not suggesting that we should fix Unix's chroot with our chroot.
However, there are a fair number of programs (namely daemons) which
understand the security holes and are able, nevertheless, to take
advantages of Unix's chroot behavior. The fact that our chroot is
less secure than Unix's deserves, I think, at least a caveat.

Thanks,
Neal

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

"Neal H. Walfield" <neal (AT) walfield (DOT) orgwrites:

I'm not suggesting that we should fix Unix's chroot with our chroot.
However, there are a fair number of programs (namely daemons) which
understand the security holes and are able, nevertheless, to take
advantages of Unix's chroot behavior. The fact that our chroot is
less secure than Unix's deserves, I think, at least a caveat.

Yes, that's a documentation bug. :)

It is possible that we should have a facility for those daemons to
use, but regardless we should make clear that the Hurd's chroot is not
a security feature.

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org