How to Run Untrusted Ruby Code Inside a Safe Sandbox

How to run untrusted Ruby code inside a safe sandbox?

$SAFE is not enough; you need to be at least at the level of Why's freaky sandbox. However, I don't know if that sandbox code is actively maintained or if he/they ever solved the holes such as infinite loops, etc.

Unsafe generally means hostile. If you can relax from hostile to, say, 'naive', and depending upon the requirements of your app, you might get away with sandboxing in Ruby. It's not really a first-class scenario in the language design.

Even with that, though, you probably don't need to go to the machine level of separation. I'd feel pretty safe using a sandbox in a separately spawned process, with your app functioning as a process manager to kill off any that manage to hang/flame. Now, that is a few orders of magnitude more work than your simple block above.

But remember and keep repeating, "SAFE can't deal with hostile".

Ruby: creating a sandboxed eval?

You might want to check the 'taint' method and related stuff. This is a good reference:

http://ruby-doc.com/docs/ProgrammingRuby/html/taint.html

Despite that, I can't advise you enough against storing code and evaluating it, it's a security risk that should be avoided and most times there's a simpler way of solving your problems.

If you need to evaluate complex rules and predicates I'd recommend a rule engine to create a nice DSL. Haven't used one in ruby but this one looks good to me:

http://treetop.rubyforge.org/index.html

Cheers

Run an untrusted C program in a sandbox in Linux that prevents it from opening files, forking, etc.?

I have used Systrace to sandbox untrusted programs both interactively and in automatic mode. It has a ptrace()-based backend which allows its use on a Linux system without special privileges, as well as a far faster and more poweful backend which requires patching the kernel.

It is also possible to create a sandbox on Unix-like systems using chroot(1), although that is not quite as easy or secure. Linux Containers and FreeBSD jails are a better alternative to chroot. Another alternative on Linux is to use a security framework like SELinux or AppArmor, which is what I would propose for production systems.

We would be able to help you more if you told as what exactly it is that you want to do.

EDIT:

Systrace would work for your case, but I think that something based on the Linux Security Model like AppArmor or SELinux is a more standard, and thus preferred, alternative, depending on your distribution.

EDIT 2:

While chroot(1) is available on most (all?) Unix-like systems, it has quite a few issues:

• It can be broken out of. If you are going to actually compile or run untrusted C programs on your system, you are especially vulnerable to this issue. And if your students are anything like mine, someone WILL try to break out of the jail.

• You have to create a full independent filesystem hierarchy with everything that is necessary for your task. You do not have to have a compiler in the chroot, but anything that is required to run the compiled programs should be included. While there are utilities that help with this, it's still not trivial.

• You have to maintain the chroot. Since it is independent, the chroot files will not be updated along with your distribution. You will have to either recreate the chroot regularly, or include the necessary update tools in it, which would essentially require that it be a full-blown Linux distribution. You will also have to keep system and user data (passwords, input files e.t.c.) synchronized with the host system.

• chroot() only protects the filesystem. It does not prevent a malicious program from opening network sockets or a badly-written one from sucking up every available resource.

The resource usage problem is common among all alternatives. Filesystem quotas will prevent programs from filling the disk. Proper ulimit (setrlimit() in C) settings can protect against memory overuse and any fork bombs, as well as put a stop to CPU hogs. nice(1) can lower the priority of those programs so that the computer can be used for any tasks that are deemed more important with no problem.

Why am I getting Insecure operation ‘write’ at level 4 when sandboxing code?

I tried your code and got the same result as you. Then I changed the $SAFE level to 3, and got this warning:

Insecure world writable dir /tmp in LOAD_PATH, mode 041777

I moved the file being loaded from /tmp to a directory that isn't world-writable and the warning went away. Changing the $SAFE level to 4 then worked.

So, try making sure that the loaded file's directory isn't world writable. Also try a lower safe level and see if you get a useful warning.

How do you set up a virtual environment or sandbox for ruby without removing access to external API's?

Use safe level and don't run the script with system

http://ruby-doc.org/docs/ProgrammingRuby/html/taint.html

This was used, for instance, in the old github gem builder (gemspecs being normal executable ruby code).

---

Related Topics