RE: Replacement for rexec/Bastion?

Discussion in 'Python' started by Michael Chermside, Aug 27, 2003.

  1. Michael Chermside writes:
    > Consider, for instance,
    > this code:
    >
    > x = 1000000**1000000
    >
    > I guarantee it'll lock up your python interpreter for a fairly long
    > time. And it executes in C so there's no possible way you can trap
    > it.


    Colin Coghill (SFive) replies:
    > I think I resolved this kind of thing a while ago by using seperate
    > processes. The user-code one and the actual application. If the
    > user-code one stops responding for some tunable time, it gets
    > kill -KILL'ed and restarted from the last checkpoint minus the
    > offending code.
    > And for resource limits, ulimit seems to work fine on the several
    > systems I've tried.
    >
    > Yes, this is messy UNIXy stuff, and loses portability, which is bad,
    > but it at least seems to make it possible to do this stuff.


    Great! If you are willing to run the untrusted code in a separate
    process and fall back on the OS to do the restricting, it _is_
    actually capable of restricting what code can perform, in a way that
    Python simply can't match. You can use ulimit and chroot to restrict
    what the untrusted code may do. Then there's no particular need to
    use ANY special restricted execution support in Python. Use Python's
    easy-to-use support for interprocess communication to make a
    simple server which runs untrusted code bits, but which is itself
    run in a separate process inside a ulimit / chroot /
    user-with-limited-permissions jail, and which is killed and restarted
    whenever it gets in trouble.

    If you DO wind up going this route, I'm guessing that the code
    to launch an untrusted-code-runner in a separate process would be
    quite popular if it were released back to the Python community,
    judging from the number of times this question gets raised.

    -- Michael Chermside
     
    Michael Chermside, Aug 27, 2003
    #1
    1. Advertising

  2. Michael Chermside

    Andrew Dalke Guest

    Michael Chermside:
    > If you DO wind up going this route, I'm guessing that the code
    > to launch an untrusted-code-runner in a separate process would be
    > quite popular if it were released back to the Python community,
    > judging from the number of times this question gets raised.


    Maybe we can convince the Twisted folks to do this? ;)

    Andrew
     
    Andrew Dalke, Aug 27, 2003
    #2
    1. Advertising

  3. "Andrew Dalke" <> writes:

    > Michael Chermside:
    > > If you DO wind up going this route, I'm guessing that the code
    > > to launch an untrusted-code-runner in a separate process would be
    > > quite popular if it were released back to the Python community,
    > > judging from the number of times this question gets raised.

    >
    > Maybe we can convince the Twisted folks to do this? ;)


    Sounds like a plan :)

    Cheers,
    mwh

    --
    I located the link but haven't bothered to re-read the article,
    preferring to post nonsense to usenet before checking my facts.
    -- Ben Wolfson, comp.lang.python
     
    Michael Hudson, Aug 27, 2003
    #3
  4. In article <>,
    Michael Chermside wrote:
    >
    > Great! If you are willing to run the untrusted code in a separate
    > process and fall back on the OS to do the restricting, it _is_
    > actually capable of restricting what code can perform, in a way that
    > Python simply can't match. You can use ulimit and chroot to restrict
    > what the untrusted code may do. Then there's no particular need to
    > use ANY special restricted execution support in Python.


    The reason I haven't just done this is that there are two problems
    I haven't solved yet, for which I appear to need help from Python itself.

    Zope's restricted python *does* look like it can solve both of these,
    I'm still figuring it out though :)

    A) Network connections
    You can't afford for the untrusted code to open an uncontrolled network
    connection, unless you're happy running a spam-repeater.
    This *could* be solved with a more secure operating system - I'm sure
    SELinux or OpenBSD could be configured to do this, but that's probably
    too large a penalty for most uses.
    I suppose if the chrooted environment provided a cut-down version of
    Python with all the dangerous stuff stripped, that could do it. But I
    suspect that'd be more work than reimplementing rexec safely.

    B) Clean sandbox
    You can't afford to restart the untrusted process between every piece
    of code its given unless you're not doing all that much processing. Only
    restarting it when something goes wrong is the ideal.
    There needs to be a way to stop one piece of code from messing up the
    environment for the next one (by creating new versions of __builtins__,
    for example.

    Ideas?


    I currently have three pieces of code:

    server.py
    sits in the main application. Provides an API, currently by xmlrpc.
    provides a "fetchNextSnippet()" which returns the next piece of code to
    be run. If it has not been called for N seconds, will kill the untrusted
    process and restart it.
    linux-safe.py
    does a chroot(), could probably do more, like setting ulimits,
    quotas, setuid?
    unsafe.py
    fetches a piece of code to run from server using the xmlrpc API.
    Runs it. That code can call methods in server.py via xmlrpc. Repeat.

    If I can solve the above two problems, I'm happy to release this code.

    The interesting thing is that linux-safe.py is the only OS-dependent part.
    Perhaps equivalents could be made for other systems. There's also no reason
    unsafe.py needs to be python, this could quite happily be a java, ruby, or
    whatever environment, if you want to use one of those as your scripting
    language.

    Using xmlrpc was only a placeholder because it was easy. This should probably
    be replaced with something pythonic, over a UNIX Domain socket or the like.

    - Colin
     
    Colin Coghill (SFive), Aug 28, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Colin Coghill (SFive)

    Replacement for rexec/Bastion?

    Colin Coghill (SFive), Aug 26, 2003, in forum: Python
    Replies:
    2
    Views:
    362
    Christian Tismer
    Aug 28, 2003
  2. Colin Coghill (SFive)

    Re: Replacement for rexec/Bastion?

    Colin Coghill (SFive), Aug 27, 2003, in forum: Python
    Replies:
    1
    Views:
    561
    Michael Hudson
    Aug 27, 2003
  3. Huaiyu Zhu

    replacement of rexec?

    Huaiyu Zhu, Oct 23, 2003, in forum: Python
    Replies:
    9
    Views:
    324
    John J. Lee
    Nov 5, 2003
  4. Erik Johnson

    recec & Bastion ?

    Erik Johnson, Apr 11, 2007, in forum: Python
    Replies:
    2
    Views:
    269
    Gabriel Genellina
    Apr 12, 2007
  5. Paul Miller

    Bastion/rexec use cases?

    Paul Miller, May 7, 2007, in forum: Python
    Replies:
    3
    Views:
    509
    Paul Boddie
    May 7, 2007
Loading...

Share This Page