views:

723

answers:

4

I want to write a server that receives and executes code on behalf of non-trusted parties.

In order to make this more secure I want the code to be run as a user that is created exclusively for running this code and then deleted.

How can I grant a non-root user the permission to create, impersonate and remove other users?

+1  A: 

Maybe you can grant permissions to non-root user with sudo and /etc/sudoers, but this way seems not secure and not linear. I don't know what you need, but maybe you can pre-create some users and then use they.

lg
A: 

You will want to use some kind of sandboxing or virtualization; at least a chroot environment at minimum. See also http://stackoverflow.com/questions/1019707/sandboxing-in-linux.

mark4o
A: 

This is a problem as you can not use su vie script without the terminal (probably a security feature). I'm sure you can hack your way through this, but it was probably done for a good reason.

Liran Orevi
+1  A: 

The only way you could conceivably do this is with a proxy program that's setuid root (i.e., chown root my-proxy-process; chmod 47nn my-proxy-process. And that setuid proxy program takes care of handling security considerations, setuid'ing to the named user, etc.

However the security problems with this should be fairly clear. One way it could be limited is to ensure your non-priveliged process runs with a user in a name group. Then chown thet proxy command with root:myprivategroup and chown it as 4710 so only users that are members of myprivategroup can execute it.

This is probably as secure as it can be. The main thing is making sure the proxy process is good and secure and locked down so only pertinent users can run it through group membership.

If there's any other restrictions you know can be applied to user-supplied processes, then the proxy program could validate that the process confers to those rules. Note that whilst this may be a stop gap, it wouldn't be beyond the realms of technology for someone to craft a "bad" program that passes the tests.

For added security (recommended), use a sandbox or chroot jail as mentioned by mark4o.

Chris J