cms-dev/isolate

Sandbox for securly executing untrusted programs

Important note

This repository is only here for historical reasons. It is not used nor updated. The authoritative version of the isolate sandbox, also used in CMS, is ioi/isolate.

isolate

Isolate is a sandbox built to safely run untrusted executables, offering them a limited-access environment and preventing them from affecting the host system. It takes advantage of features specific to the Linux kernel, like namespaces and control groups.

Isolate was developed by Martin Mareš ([email protected]) and Bernard Blackham ([email protected]), who still maintain it. Several other people contributed patches for features and bug fixes (see Git history for a list). Thanks!

Originally, Isolate was a part of the Moe Contest Environment, but it evolved to a separate project used by different contest systems, most prominently CMS. It now lives at GitHub, where you can submit bug reports and feature requests.

If you are interested in more details, please read Martin's and Bernard's paper presented at the IOI Conference. Also, Isolate's manual page is available online.

isolate's Issues

Share namespaces between boxes

Currently there is no way to share namespaces between the different boxes.
As I would need this feature to sandbox processes that needs to communicate between them using sockets, I want to add a feature which would allow you to specify that you want a box to share the same network namespace than another one, so that isolate could setns(2) just after the box is created.
As I'm not really familiar with this project, I'd like to know what would be the best way to implement this functionality in the current code.

Thanks!

isolate not killing immediately after time limit

See cms-dev/cms#202.

Isolate doesn't exit - worker waits indefinitely

See cms-dev/cms#259.

Sandbox outputs "/tmp/box/?" on the shell

See cms-dev/cms#132.

Sandbox causes kernel panic

See cms-dev/cms#140.

g++: error trying to exec 'cc1plus': execvp: No such file or directory

I'm trying to compile a c++ file inside the box and I'm getting:

g++ -std=c++11 -Wall -Wextra -O2 gencode.cpp -o gencode.exe
g++: error trying to exec 'cc1plus': execvp: No such file or directory

Status of this repo?

It took me awhile to find out that cms/isolate submodule links to https://github.com/ioi/isolate and not this repository.

So, whats the status of the current repo? Is it outdated? I think some clarification in the description and readme is necessary.

`make install` rule

It would be really convenient to have a make install rule that installs the manpage and the binary in the prefix. That would allow for easier packaging of isolate.

SIGABORT reported as signal 11

See cms-dev/cms#141.

execve: No such file or directory/Signal 11 when using -vv

I downloaded CMS, configured it, however when testing a problem all tests fail with Signal 11. Now, I narrowed the problem down to the isolate binary - I try to run:

isolate --init
isolate --run -- <path_to_static_binary>

I have verified that the statically linked binary is correct and that it runs without the isolate command. However, the second command above fails with the message:
execve(<path_to_static_binary>): No such file or directory
If I add the -vv flag, then the error becomes
Caught fatal signal 11

How can I debug this? I'm running it without cgroups and the kernel supports the necessary features. I'm using Fedora 26 if that matters.

Sandbox does not set file size limit

See cms-dev/cms#309.

Some systemd-specific code will (probably) be required soon

I'd like to draw attention to this document:

http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/

from which I quote:

In the short-term future writing directly to the control group tree from applications should still be OK, as long as the Pax Control Groups [1] document is followed. In the medium-term future it will still be supported to alter/read individual attributes of cgroups directly, but no longer to create/delete cgroups without using the systemd API. In the longer-term future altering/reading attributes will also be unavailable to userspace applications, unless done via systemd's APIs (either D-Bus based IPC APIs or shared library APIs for passive operations).

I'm not aware of the current status of that document and of the plans it describes (whether they're abandoned, confirmed, already achieved, etc.) but, if those goals will be fulfilled, isolate won't be able to operate as it does now.

I know that some people don't agree with the attitude of systemd developers towards pushing for new standards and conventions (and neither do I, in this occasion) but systemd is now part of most Linux distributions (including Ubuntu, our favorite target), meaning we have to deal with it.

Finally, I'd like to express a personal opinion: isolate's use of cgroups is quite simple, in that it creates only a handful of cgroups that it keeps for its personal use, without any interaction with the rest of the system. Moreover, there seem to be very few pieces of software that use cgroups (at least that's what I've noticed in my experience) and systemd is probably the major one, also considering its role in setting up and organizing the system's hierarchy. I therefore consider it to be of value to "play along nicely" with systemd.

[1] http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups/

Hardcoded cgroups and box directory

Currently the location of the cgroup mount (e.g. /sys/fs/cgroup) is hardcoded in autoconf.h. In reality every system seems to have its own traditions with regards to the mount point (I've seen /mnt/cgroup and /cgroup too), moreover some decide to not follow the tradition at all.

Constructive suggestion:

• Add a command line option specifying the location of the cgroup mount.
• When this is not available, check /sys/fs/cgroup, /cgroup and /mnt/cgroup for the necessary files. If not found, fail with a descriptive message.

I can implement that, if you consider this approach reasonable.
On a sidenote, none of the values currently in autoconf.h should be hardcoded. A configfile/commandline parameter for each of those would be helpful.

KeyError: 'getpwuid(): uid not found: 60002'

When I run Python code with isolate, I receive this error:

Failed to import the site module
Traceback (most recent call last):
  File "/usr/lib/python3.6/site.py", line 544, in <module>
    main()
  File "/usr/lib/python3.6/site.py", line 530, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/lib/python3.6/site.py", line 282, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/lib/python3.6/site.py", line 258, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/lib/python3.6/site.py", line 248, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/lib/python3.6/sysconfig.py", line 601, in get_config_var
    return get_config_vars().get(name)
  File "/usr/lib/python3.6/sysconfig.py", line 558, in get_config_vars
    _CONFIG_VARS['userbase'] = _getuserbase()
  File "/usr/lib/python3.6/sysconfig.py", line 205, in _getuserbase
    return joinuser("~", ".local")
  File "/usr/lib/python3.6/sysconfig.py", line 184, in joinuser
    return os.path.expanduser(os.path.join(*args))
  File "/usr/lib/python3.6/posixpath.py", line 247, in expanduser
    userhome = pwd.getpwuid(os.getuid()).pw_dir
KeyError: 'getpwuid(): uid not found: 60002'
Exited with error status 1

I did that operations:

cd `isolate --box-id 3 --init`/box
cat > a.py

#!/bin/python
print ("asdf")

chmod +x a.py
isolate --box-id 3 --run -- ./a.py

Which one is the actual project upstream?

Is it https://github.com/cms-dev/isolate or https://github.com/ioi/isolate? Where should we submit patches and issues? Shouldn't the other repository disable issue creation and redirect to the other projects?

isolate fails to set stack limit to infinity

I tried to run isolate on a very recent linux kernel (4.14.0-2-amd64) and for some reason isolate fails to set the stack limit. The problem is not very specific to isolate but rather with that line of code:

RLIM(STACK, (stack_limit ? (rlim_t)stack_limit * 1024 : RLIM_INFINITY));

Note that it happens even if isolate is called without enforcing any memory limit. For example this produce the problem on my computer:

/usr/local/bin/isolate --init --box-id=42
/usr/local/bin/isolate --run --box-id=42 -- ./hello
/usr/local/bin/isolate --cleanup --box-id=42

It seems that on recent kernels, trying to call setrlimit for the STACK with infinity fails with "Operation not permitted". I have not been able to find out why this is the case, but clearly this is a change of behavior because on an older 3.16 kernel, it works flawlessly.