On 04/07/2018 18:42, Ivan Shmakov wrote:

Ben Bacarisse <[email protected]> writes:
Ivan Shmakov <[email protected]> writes:

Debian offers schroot(1)
for this purpose ($ schroot -c mychroot -- [COMMAND]...;
if no COMMAND given, an interactive shell is started.)

Note for BSD users, I have ported schroot to FreeBSD on the current
master branch at

https://gitlab.com/codelibre/schroot

however, I've lacked the time to comprehensively test and release this.
This was primarily adding support for OpenPAM in place of Linux-PAM and
using getmntinfo(3) in place of /proc/mounts.

If anyone is interested in using schroot on FreeBSD, or adding anything additional to support other BSD systems, please do get in touch.


Regards,
Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ivan Shmakov <[email protected]> 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.

In Linux-based systems, this presumably can be mitigated by
using the CLONE_NEWPID option to clone(2) syscall [1], resulting
in the process running in a brand new process id namespace.
Unfortunately, AIUI, this would also prevent the use of
ptrace(2) the other way around, thus precluding, say, the use of
a trusted debugger of the base system on a chrooted (or, rather,
pid-isolated) process.

Also, this feature is not yet supported by Debian schroot(1) [2].

[1] clone, __clone2: create a child process
URI: http://manpages.debian.org/stretch/manpages-dev/clone.2.en.html
[2] Provide PID isolation (using a namespace)
URI: http://bugs.debian.org/707233

A somewhat less serious issue is that, in some cases, interactive
software may need (or want) access to the device file corresponding
to its controlling tty, often a pty, which means that it may be
necessary to share the whole /dev/pts hierarchy between the base
system and the chroot (or at the least, I don't know an easy way
to share just a specific pty), thus making it possible for
chrooted processes to interact with ptys of non-chrooted ones.

A Linux-specific alternative (again) would be to mount a
separate /dev/pts hierarchy under chroot and, say, run a
terminal emulator for X from chroot. Unfortunately, that means
giving said emulator access to one's X display, which arguably
is no less risky than giving access to one's ptys. Unless, of
course, a "nested" X server (such as Xnest or Xephyr) is used.

Overall, I'd say that the chroot(2) mechanism in general and
schroot(8) in particular should not be mistaken for a security
measure, but still can be used to run software trusted equally
to that which comprises the base system. Thus, using a Debian
oldstable chroot under Debian stable base is hardly a problem,
whereas using an Ubuntu chroot under the same may already be
questionable.

[...]

--
FSF associate member #7257 http://am-1.org/~ivan/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Ivan Shmakov <[email protected]> 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.

--
Barry Margolin, [email protected]
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Barry Margolin <[email protected]> writes:
In article <[email protected]>, 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?

The "entire pid space" is less than 32767 for me, so that
doesn't seem like a particularly difficult task. However,
certain applications require /proc, and when provided, it
allows for a way more efficient search.

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.

Worse still, this seem to preclude the use of schroot(1).

One of the use cases for having a variety of OS versions
installed is running scientific software, which tends to be
rather picky with respect to the versions of libraries (and
sometimes development tools and other software), even when
compiled from source.

So, the idea was to install a rather basic (Debian GNU/Linux)
system on the hosts, and provide as many chroots as the users
would need; including possibly non-Debian Linux-based systems.

That, of course, means that these other systems are either to be
trusted equally, and plain chroot(8) is used for administrative
tasks (like: # chroot /chroot/foo install-package bar), or these
chroots need to double as fully bootable systems for, say, QEMU.

Of course, it still means that the /user/ who requests such a
system trusts it sufficiently, but that sounds more or less
acceptable.

--
FSF associate member #7257 http://am-1.org/~ivan/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)