Debian offers schroot(1)Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
Ivan Shmakov <ivan@siamics.net> writes:
for this purpose ($ schroot -c mychroot -- [COMMAND]...;
if no COMMAND given, an interactive shell is started.)
Ivan Shmakov <ivan@siamics.net> writes:
Chroot environments provide a degree of isolation, as processes with
a root directory set to /otherwhere cannot access filenames outside
of said directory. (Although it's still possible for a chrooted
process to inherit or receive a file descriptor from a non-chrooted process.) Of course, processes running as root are still fully
privileged, and can, for instance, create device files and thence
wreak any kind of havoc on the system as a whole.
Additional syscalls are available to further isolate processes, which
can be used alongside chroot(2). These are the basis for, e. g.,
FreeBSD "jails" and Linux "containers" (LXC.)
I've recently realized that even non-privileged chrooted
processes can still issue the ptrace(2) system call to
non-chrooted ones (running under the same uid), thus making
this kind of isolation ineffective.
Barry Margolin <barmar@alum.mit.edu> writes:
In article <8736whhp8u.fsf@violet.siamics.net>, Ivan Shmakov wrote:
I've recently realized that even non-privileged chrooted processes
can still issue the ptrace(2) system call to non-chrooted ones
(running under the same uid), thus making this kind of isolation
ineffective.
How is it supposed to find that other process? Loop through the
entire PID space, calling ptrace() until it succeeds?
A simple way to mitigate this is to NOT run any processes outside the
chroot jail under the same UID as the prisoner.
Yeah, this does preclude running a debugger outside the jail to debug
the jailed process, like the problem you pointed out with CLONE_NEWPID.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 85:59:18 |
Calls: | 6,658 |
Files: | 12,203 |
Messages: | 5,333,783 |