perlbot / app-evalserveradvanced

NAME

App::EvalServerAdvanced - A more featured update to App::EvalServer

DESCRIPTION

This is a complete redesign and rewrite of the original code behind App::EvalServer.

This code is only BETA quality at best. See the USE section below for more information.

FEATURES

Features over App::EvalServer

Use of Linux namespaces.

The chroot is accompanied by a private mounted tmpfs filesystem. This allows a safe writable /tmp that won't be seen by anyone else. The evaluated code is placed in it's own PID space. This helps prevent it from sending signals to anything else that might be running.

Use of Seccomp

More featureful sandboxing with Seccomp rules. This helps prevent anything running from issuing any potentially dangerous system calls.

Formal network protocol.

You can send multiple requests per connection, and wait on them asynchronously. This helps enable better scheduling and handling of batch actions, and allows you to cancel inflight requests. This also allows the cancelling, by the client, of a long running job while it's running.

USE

You're going to want to review at least the source of App::EvalServerAdvanced::Sandbox and App::EvalServerAdvanced::Seccomp. These two modules are responsible for most of the security features of the whole system. Familiarity with them is HIGHLY recommended.

Included in this dist is a command esa-makesandbox that will create a skeleton for a sandbox for you with my opinionated recommendations.

SECURITY

This system exercises a series of defense in depth measures. However they are not perfect. If a kernel level exploit exists to get higher privileges (Dirty COW is a good example), it could be used to write to any bind mounted directory.

My recommendations for extra protection are to use a copy of a running system in the sandbox, and not actually use the /lib64 directories from the existing system. This wouldn't prevent someone from leaving something behind, but would prevent it from being accessed accidentally from the original system.

Take a look at something like debootstrap to create a skeleton debian based system to use in the sandbox.

WARRANTY

There is none. You use this at your own risk. It is opinionated about what is secure, but it probably isn't secure. This software will result in the hacking of everyone around you.

TODO

Create some kind of pluggable system for specifiying additional Seccomp rules

Create another pluggable system for extending App::EvalServer::Sandbox::Internal with additional subs

Finish enabling full configuration of the sandbox without having to edit any code

SEE ALSO

App::EvalServerAdvanced::REPL, App::EvalServerAdvanced::Protocol

AUTHOR

Ryan Voots <[email protected]>

app-evalserveradvanced's Issues

Use dup2() to get a new FD for STDERR and keep fd 2 open

This way STDERR looks normal to the code that's running, without a fork and exec. This will fix Devel::Peek and allow for more perl versions to use the run_perl wrapper rather than the other versions.

Sandbox plugins have issues with @INC

As the current way of loading them fucks with @inc for security it causes them to be unable to load modules. Copy the method used by Seccomp plugins

__DATA__ doesn't work

see https://perlbot.pl/p/9lydqh

Seccomp actions don't allow constants

action: ERRNO(EACCES)

should work, with the constants loaded by the plugins.

%ENV from config doesn't work

Does not get set as expected in the sandbox