search

SeattleTestbed / repy_v2

Seattle Testbed's Repy ("Restricted Python") sandbox, version 2
MIT License
12 stars 50 forks source link

Need to support machine owner selected security layers in an intelligent way. #3

Open choksi81 opened 10 years ago

choksi81 commented 10 years ago

Somehow, we need to add good support for the owner of the computer to select a set of security layers. These should be used by any sandboxed process that executes code on the machine.

The challenges include ensuring that the sandboxed program can't overwrite the code and persisting across vessel splits / joins. This mostly needs to be added for V2 (it's not as relevant to V1).

choksi81 commented 10 years ago

Author: justinc Has this been addressed?

choksi81 commented 10 years ago

Author: mkaplan We should verify that the repyv2 nodemanager has the ability to run repy with security layers.

If it does not have that functionality, it should be added via cmd line arguments and argparse.

choksi81 commented 10 years ago

Author: mkaplan The functionality is currently not there.

Because of the numerous changes to the repyv1 nodemanager, we'll port that over, add in the repyv2 changes, and an option to parse security layers.

Additionally, we'll need to replace calls to 'python' with sys.executable. I specifically saw this in the repyv1 nmAPI.mix line 247.

This is the call stack in repyv2. In order to add support for the security layers, we may need to modify these functions:

nmmain.main() nmmain.start_worker_thread() nmconnectionmanager.WorkerThread nmrequesthandler.handle_request - Line 69, 92 nmrequesthandler.process_API_call() - Line 182, 196 nmAPI.startvessel() - Line 229, 240

choksi81 commented 10 years ago

Author: mkaplan The difficulty is that the API calls are stateless, and do not support any predefined settings. As far as I can tell, the only way to do this (without even more extensive changes) would be to create a global in nmAPI, and then have nmmain.py directly modify it from the command line arguments, similar to the way repy.py does when setting up the emulcomm module initially. This is not a preferred way to do things, but without using classes for storing the 'global' state, I do not see a better way.

To explain the previously described stack trace:

The requesthandler function calls the relevant function via a lookup. In our case, the lookup is "StartVessel", which refers to nmAPI.startvessel

nmrequesthandler.py: line 182 numberofargs, permissiontype, APIfunction = API_dict[callname]

nmAPI.mix: line 234 startvessel() repy.py is called here

A separate but slightly unrelated concern is the fact that it appears that the nodemanager launches repy in nmAPI.startvessel(), but doesn't include the restrictions file. I do not understand how this is so.

choksi81 commented 10 years ago

Author: justinc Replying to mkaplan:

The difficulty is that the API calls are stateless, and do not support any predefined settings. As far as I can tell, the only way to do this (without even more extensive changes) would be to create a global in nmAPI, and then have nmmain.py directly modify it from the command line arguments, similar to the way repy.py does when setting up the emulcomm module initially. This is not a preferred way to do things, but without using classes for storing the 'global' state, I do not see a better way.

I'm confused. What is wrong with the technique used in Repy V1?

The installer has a command line option and by setting this, the node manager configuration file gets a setting that says which security laters to prepend when repy is instantiated.

Does this not work for some reason?

A separate but slightly unrelated concern is the fact that it appears that the nodemanager launches repy in nmAPI.startvessel(), but doesn't include the restrictions file. I do not understand how this is so.

I think you may be confused by the option that disables restrictions. This stops the 'call allow', etc. syntax from being obeys, but does not stop the resource / restriction file from being used.

choksi81 commented 10 years ago

Author: sportzer r4454 and r4458 added security layers to repy v1, which could be relevant

choksi81 commented 10 years ago

Author: mkaplan Carried over the changes from r4454 and r4458 in r5750 and r5751. The installer for repyv2 will need to be modified as well, but that is not part of repyv2 yet, and as such, that cannot be done at this time.