Re: Replacing rexec

Discussion in 'Python' started by Aahz, Jul 16, 2003.

  1. Aahz

    Aahz Guest

    In article <>,
    Tim Gerla <> wrote:
    >
    >We are looking to use plpython in PostgreSQL, but it's being downgraded
    >to "untrusted" and/or being completely removed because Python's rexec
    >went away. Why did rexec go away, specifically? I know it had security
    >issues, but couldn't these have been fixed? Did the module just have too
    >many integral flaws in the design to be worth saving?


    There are two separate issues:

    * rexec implementation -- it never had a true security audit, and there
    have never been resources to do it.

    * rexec vs new-style classes -- the basic mechanism used in rexec fails
    in the fact of new-style classes, which would require a complete rewrite
    of rexec.

    >Is anyone working on a replacement? If not, why not? Even if plpython
    >isn't very widely used, I think it's still important for advocacy. I'd
    >much rather write Python than PL.


    There's been some talk, but it's likely that a secure Python will
    require forking the code. Note that it's already too easy to write a
    DoS attack against Python: 100L**100**100 will do it. Conversely, if
    only trusted code is going into the server, there's no need for rexec.

    >Anyway, I'm looking for a summary of specific reasons why rexec went
    >away without a replacement. I understand completely that it had flaws
    >and was insecure; I'm only confused as to why these flaws were
    >insurmountable.


    Take a look at http://www.amk.ca/python/howto/rexec/
    --
    Aahz () <*> http://www.pythoncraft.com/

    A: No.
    Q: Is top-posting okay?
     
    Aahz, Jul 16, 2003
    #1
    1. Advertising

  2. Aahz

    John J. Lee Guest

    (Aahz) writes:
    [...]
    > There's been some talk, but it's likely that a secure Python will
    > require forking the code. Note that it's already too easy to write a
    > DoS attack against Python: 100L**100**100 will do it. Conversely, if
    > only trusted code is going into the server, there's no need for rexec.

    [...]

    I don't see how it's possible to prevent that, whatever language
    you're using.

    http://www.securingjava.com/chapter-four/chapter-four-3.html

    | It is ironic that some of the most Java-heavy Web pages almost go as
    | far as denial of service in doing what their programmers intended

    <0.3 wink>

    Isn't it true that the only solution to a program taking up too much
    of a system's resources is to cap its resource usage, or stop it
    running? Usually, it's the OSs job to do that (which you might view
    as almost the definition of an OS, perhaps) -- is that a bad thing?


    John
     
    John J. Lee, Jul 17, 2003
    #2
    1. Advertising

  3. (John J. Lee) writes:

    > Isn't it true that the only solution to a program taking up too much
    > of a system's resources is to cap its resource usage, or stop it
    > running? Usually, it's the OSs job to do that (which you might view
    > as almost the definition of an OS, perhaps) -- is that a bad thing?


    I wouldn't say so, and in some circumstances you can use the OS to
    limit the other sorts of damage a rogue script can do (chroot(),
    jail(), whatever). If I had to worry about these sorts of things
    (which I don't), this would probably be the first place I'd look.

    Cheers,
    M.

    --
    ... when all the programmes on all the channels actually were made
    by actors with cleft pallettes speaking lines by dyslexic writers
    filmed by blind cameramen instead of merely seeming like that, it
    somehow made the whole thing more worthwhile. -- HHGTG, Episode 11
     
    Michael Hudson, Jul 17, 2003
    #3
  4. On Thu, Jul 17, 2003 at 01:14:02PM -0000, Moshe Zadka wrote:
    > [Aahz]
    > > require forking the code. Note that it's already too easy to write a
    > > DoS attack against Python: 100L**100**100 will do it. Conversely, if
    > > only trusted code is going into the server, there's no need for rexec.

    >
    > [John J. Lee]
    > > I don't see how it's possible to prevent that, whatever language
    > > you're using.

    >
    > Limits on memory and CPU ticks used by untrusted code.
    > This brand new, cutting edge technology is not yet available, and
    > LambdaMOO was, of course, a product of Guido misusing the time-machine.
    > Which doesn't exist itself, either.


    MUD interpreters [I only know the LPC interpreter first hand] were designed
    for this from the ground up. A single operation couldn't spin the CPU
    forever or consume a world's worth of memory. They did this badly.
    It wasn't possible to crash a MUD but you could bring one to its knees by
    using LIMIT-1 of every resource every bump. MUDs also have an advantage
    because the people writing code are hand picked. They have a stake in doing
    the right thing so they rarely write malicious code.

    -jack
     
    Jack Diederich, Jul 17, 2003
    #4
  5. Aahz

    Asun Friere Guest

    Jack Diederich <> wrote in message news:<>...

    > MUDs also have an advantage
    > because the people writing code are hand picked. They have a stake in doing
    > the right thing so they rarely write malicious code.


    Not so with most MOOs (MOO was designed from the ground up to be
    programmable
    via a prototyping OO language (the OO in MOO) by any user with a prog
    bit set), where almost anyone is given programming privleges. In fact
    the only requirement, AFAIK (and it's been a while), on the MOO cited
    (LambdaMOO), is membership of one month standing.
     
    Asun Friere, Jul 18, 2003
    #5
    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:
    359
    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:
    560
    Michael Hudson
    Aug 27, 2003
  3. Michael Chermside

    RE: Replacement for rexec/Bastion?

    Michael Chermside, Aug 27, 2003, in forum: Python
    Replies:
    3
    Views:
    532
    Colin Coghill (SFive)
    Aug 28, 2003
  4. Rainer Deyke

    Now that rexec is gone...

    Rainer Deyke, Sep 27, 2003, in forum: Python
    Replies:
    13
    Views:
    536
  5. Huaiyu Zhu

    replacement of rexec?

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

Share This Page