change the userid to a pool of worker ids when executing code

[jasongrout]

We should not run user code as the untrusted device user. Instead, when forking to create a worker, change user id to some pool of userids, so user code cannot, for example killall python to kill the untrusted device.

See http://groups.google.com/group/sage-notebook/msg/93fe5fb56596242d

[kramer314]

This initially seems to require a bit more than just running code from a pool of users; right now, os.system("killall python") kills the trusted side of the device too.

Also, this definitely seems reasonable to implement, but what are the advantages of this over something like a chroot jail, whitelisting/blacklisting specific modules by providing a custom import statement or other sandboxing techniques? Granted, I'm not very familiar with best security procedures for this, but I thought the point of SSH-ing into an "untrusted" account in the first place was so that we could assume the untrusted account (if properly set up) was secured to the point where a user executing arbitrary code like killall python would not be able to do much.

[jasongrout]

It doesn't kill the trusted side if the untrusted side is running as a different user. Are you running the trusted and untrusted sides as different users?

Our concern before was that the user would not be able to touch the trusted side or the database. However, we assumed the untrusted user could wreck havoc on the untrusted side. In particular, since all untrusted accounts are running as the same user, the untrusted code could certainly change things for any other untrusted execution.

One way to solve the issue is to have the untrusted manager running as root or at least with permissions to change UID. Then before executing user code, the untrusted manager forks itself, changes UID to a random, very unprivileged account, and only then executes code. The bad thing is that means that Sage has to be running as root or with root-like privileges (to be able to do a setuid on its child).

[jasongrout]

There are a lot of sandboxing techniques which are a lot of overhead and tricky to implement. Our hope was to use the operating system and virtual machines to provide the sandboxing in a much easier way.

[kramer314]

It doesn't kill the trusted side if the untrusted side is running as a different user. Are you running the trusted and untrusted sides as different users?

Nope, I wasn't (and I'm not entirely sure why I wasn't), and doing so fixed that problem.

Also, this looks very relevant: http://code.google.com/p/setuid-sandbox/ (although it's linux-only)