| nchip ( @ 2006-07-25 22:45:00 |
Dear lazyweb..
Relatively simple task - given a pid, find out if it is in the same chroot as you. Until now we simply used the following code, which would error out if the given pid was not in chroot like us:
All good things end up eventually, this time with the soon to come out 2.6.18 Linux kernel release. A recent commit changes the permissions of symlinks in /proc, (not only /proc/$pid/fd like it would seem from the commit message). Using ptrace as security policy is not a bad idea. If you can access the information via ptrace, hiding it from /proc made little sense. Which leads to the scary observation that one can ptrace any process with same UID outside your chroot sandbox. This is not a security bug, since one can escape chroot anyway. I just hadn't realized *HOW* easy it was.
Back to the topic, using /proc/$pid/root was not a standard or even documented interface, so I can hardly complain. I'm still left without a proper replacement:
So what AM I supposed to use?
Relatively simple task - given a pid, find out if it is in the same chroot as you. Until now we simply used the following code, which would error out if the given pid was not in chroot like us:
readlink /proc/$pid/rootAll good things end up eventually, this time with the soon to come out 2.6.18 Linux kernel release. A recent commit changes the permissions of symlinks in /proc, (not only /proc/$pid/fd like it would seem from the commit message). Using ptrace as security policy is not a bad idea. If you can access the information via ptrace, hiding it from /proc made little sense. Which leads to the scary observation that one can ptrace any process with same UID outside your chroot sandbox. This is not a security bug, since one can escape chroot anyway. I just hadn't realized *HOW* easy it was.
Back to the topic, using /proc/$pid/root was not a standard or even documented interface, so I can hardly complain. I'm still left without a proper replacement:
So what AM I supposed to use?