Python as network protocol

Discussion in 'Python' started by Cooch, Nov 10, 2009.

  1. Cooch

    Cooch Guest

    Hi, guys!

    I want to implement such specific feature:
    I have a server written in Python. I have a client written in C++. I
    want to use Python as network protocol between them. I mean: client
    send to server such string: "a = MyObject()", so object of this type
    will appear in server. Any ideas how to simplify this implementation?
    I make XML-RPC/SOAP server using twisted which just execute sended
    string. But I don't know how to:
    1. Restrict usage of some modules on client side (os, sys etc..)
    2. Divide variables of different clients. Generally, I know that I
    should use "exec .. in .. " construct, but don't know how to
    distinguish between clients in twisted.

    Dmitry.
     
    Cooch, Nov 10, 2009
    #1
    1. Advertising

  2. Cooch schrieb:
    > Hi, guys!
    >
    > I want to implement such specific feature:
    > I have a server written in Python. I have a client written in C++. I
    > want to use Python as network protocol between them. I mean: client
    > send to server such string: "a = MyObject()", so object of this type
    > will appear in server. Any ideas how to simplify this implementation?
    > I make XML-RPC/SOAP server using twisted which just execute sended
    > string. But I don't know how to:
    > 1. Restrict usage of some modules on client side (os, sys etc..)
    > 2. Divide variables of different clients. Generally, I know that I
    > should use "exec .. in .. " construct, but don't know how to
    > distinguish between clients in twisted.


    This is a *really* bad idea. Because there is no real way to restrict
    execution in python, and thus you allow clients to inject arbitrary code
    into your server. Including the notorious "os.system('rm -rf /')".

    So - don't do that. Use e.g. CORBA if you need a richer, object-base
    protocol than XMLRPC.

    Diez
     
    Diez B. Roggisch, Nov 10, 2009
    #2
    1. Advertising

  3. >> I want to implement such specific feature:
    >> I have a server written in Python. I have a client written in C++. I
    >> want to use Python as network protocol between them. I mean: client
    >> send to server such string: "a = MyObject()", so object of this type
    >> will appear in server. Any ideas how to simplify this implementation?
    >> I make XML-RPC/SOAP server using twisted which just execute sended
    >> string. But I don't know how to:
    >> 1. Restrict usage of some modules on client side (os, sys etc..)
    >> 2. Divide variables of different clients. Generally, I know that I
    >> should use "exec .. in .. " construct, but don't know how to
    >> distinguish between clients in twisted.


    Have you considered using pyro?

    http://pyro.sourceforge.net/

    > This is a *really* bad idea.


    How do you know for sure? Maybe the OP wants to use this thing with 3
    known researchers working on a cluster that is not even visible to the
    outside world. In such a setup the model the OP suggested is a
    perfectly reasonable one. I say this because I often work in such an
    environment and security is never an issue for us. And I find it
    always amusing that whenever I outline our code to a non-scientist
    programmer they always run away in shock and never talk to us again :)
    Nevertheless our code works perfectly for our purposes.

    > Because there is no real way to restrict
    > execution in python, and thus you allow clients to inject arbitrary code
    > into your server. Including the notorious "os.system('rm -rf /')".
    >
    > So - don't do that. Use e.g. CORBA if you need a richer, object-base
    > protocol than XMLRPC.


    Cheers,
    Daniel

    --
    Psss, psss, put it down! - http://www.cafepress.com/putitdown
     
    Daniel Fetchinson, Nov 10, 2009
    #3
  4. Cooch

    Martin Guest

    On Tue, Nov 10, 2009 at 16:31, Daniel Fetchinson
    <> wrote:
    >> This is a *really* bad idea.

    >
    > How do you know for sure? Maybe the OP wants to use this thing with 3
    > known researchers working on a cluster that is not even visible to the
    > outside world. In such a setup the model the OP suggested is a
    > perfectly reasonable one. I say this because I often work in such an
    > environment and security is never an issue for us. And I find it
    > always amusing that whenever I outline our code to a non-scientist
    > programmer they always run away in shock and never talk to us again :)
    > Nevertheless our code works perfectly for our purposes.


    It is a bad idea because that's exactly why we now have a spam
    problem. It _was_ a trusted environment once upon a time. Just check
    your spam messages to see why ignoring security can lead to really bad
    results.

    Do you know for sure that in say 3-5 years from now on your software
    isn't released into the wild and then has no security at all?

    regards,
    Martin


    --
    http://www.xing.com/profile/Martin_Marcher
    http://www.linkedin.com/in/martinmarcher

    You are not free to read this message,
    by doing so, you have violated my licence
    and are required to urinate publicly. Thank you.

    Please avoid sending me Word or PowerPoint attachments.
    See http://www.gnu.org/philosophy/no-word-attachments.html
     
    Martin, Nov 10, 2009
    #4
  5. On Tue, 10 Nov 2009 16:31:13 +0100, Daniel Fetchinson wrote about using
    exec:

    >> This is a *really* bad idea.

    >
    > How do you know for sure? Maybe the OP wants to use this thing with 3
    > known researchers working on a cluster that is not even visible to the
    > outside world. In such a setup the model the OP suggested is a perfectly
    > reasonable one. I say this because I often work in such an environment
    > and security is never an issue for us. And I find it always amusing that
    > whenever I outline our code to a non-scientist programmer they always
    > run away in shock and never talk to us again


    You might be a great scientist, but perhaps you should pay attention to
    the experts on programming who tell you that this is opening a potential
    security hole in your system.

    No, it's not a "perfectly reasonable" tactic. It's a risky tactic that
    only works because the environment you use it in is so limited and the
    users so trusted. Can you guarantee that will never change? If not, then
    you should rethink your tactic of using exec.

    Besides, as a general rule, exec is around an order of magnitude slower
    than running code directly. If performance matters at all, you are better
    off to try to find an alternative to exec.


    > Nevertheless our code works perfectly for our purposes.


    Until the day that some manager decides that it would be great to make
    your code into a service available over the Internet, or until one of the
    other scientists decides that he really needs to access it from home, or
    somebody pastes the wrong text into the application and it blows up in
    your face... it's not just malice you need to be careful of, but also
    accidents.

    The history of computing is full of systems that were designed with no
    security because it wasn't needed, until it was needed, but it was too
    late by then.

    There's no need, or at least very little need, to put locks on the
    internal doors of your house, because we're not in the habit of taking
    internal doors and turning them into outside doors. But code designed to
    run inside your secure, safe network has a tendency to be re-purposed to
    run in insecure, unsafe networks, usually by people who have forgotten,
    or never knew, that they were opening up their system to code injection
    attacks.



    --
    Steven
     
    Steven D'Aprano, Nov 10, 2009
    #5
  6. On 2009-11-10, Steven D'Aprano <> wrote:
    > On Tue, 10 Nov 2009 16:31:13 +0100, Daniel Fetchinson wrote about using
    > exec:
    >
    >>> This is a *really* bad idea.

    >>
    >> How do you know for sure? Maybe the OP wants to use this thing
    >> with 3 known researchers working on a cluster that is not even
    >> visible to the outside world.


    And those three researchers are perfect? They've never even
    made a typographical error?

    >> In such a setup the model the OP suggested is a perfectly
    >> reasonable one. I say this because I often work in such an
    >> environment and security is never an issue for us. And I find
    >> it always amusing that whenever I outline our code to a
    >> non-scientist programmer they always run away in shock and
    >> never talk to us again

    >
    > You might be a great scientist, but perhaps you should pay
    > attention to the experts on programming who tell you that this
    > is opening a potential security hole in your system.
    >
    > No, it's not a "perfectly reasonable" tactic. It's a risky
    > tactic that only works because the environment you use it in
    > is so limited and the users so trusted.


    Even then it only works until a trusted user makes a mistake
    and types the wrong thing. A stupid mistake can do just as much
    damage as an evil mastermind.

    --
    Grant Edwards grante Yow! Is this an out-take
    at from the "BRADY BUNCH"?
    visi.com
     
    Grant Edwards, Nov 10, 2009
    #6
  7. Daniel Fetchinson schrieb:
    >>> I want to implement such specific feature:
    >>> I have a server written in Python. I have a client written in C++. I
    >>> want to use Python as network protocol between them. I mean: client
    >>> send to server such string: "a = MyObject()", so object of this type
    >>> will appear in server. Any ideas how to simplify this implementation?
    >>> I make XML-RPC/SOAP server using twisted which just execute sended
    >>> string. But I don't know how to:
    >>> 1. Restrict usage of some modules on client side (os, sys etc..)
    >>> 2. Divide variables of different clients. Generally, I know that I
    >>> should use "exec .. in .. " construct, but don't know how to
    >>> distinguish between clients in twisted.

    >
    > Have you considered using pyro?
    >
    > http://pyro.sourceforge.net/


    Have you considered that C++ doesn't support Pyro?


    >
    >> This is a *really* bad idea.

    >
    > How do you know for sure? Maybe the OP wants to use this thing with 3
    > known researchers working on a cluster that is not even visible to the
    > outside world. In such a setup the model the OP suggested is a
    > perfectly reasonable one. I say this because I often work in such an
    > environment and security is never an issue for us. And I find it
    > always amusing that whenever I outline our code to a non-scientist
    > programmer they always run away in shock and never talk to us again :)
    > Nevertheless our code works perfectly for our purposes.


    If you read the OP message, he himself stated that he wants to lock down
    the interpreter. Which isn't possible. So (scientific) reasoning can
    tell us that his application might not run in a happy-go-lucky
    environment of scientific research.

    Additionally, there is always the option of mistakes being made
    involuntarily, so desigining a system that encourages these is a bad idea.

    And last but not least, instead of having a well-defined protocol
    relying on arbitrary in-process manipulation is a nightmare to maintain,
    and might well lead to nasty bugs, crashes or even subtler problems
    (think changing a global constant for all the others...) that are nearly
    impossible to debug.

    Plus the issues the others mentioned.

    Diez
     
    Diez B. Roggisch, Nov 10, 2009
    #7
  8. On Tue, Nov 10, 2009 at 10:56 AM, Steven D'Aprano
    <> wrote:
    > On Tue, 10 Nov 2009 16:31:13 +0100, Daniel Fetchinson wrote about using
    > exec:
    >
    >>> This is a *really* bad idea.

    >>
    >> How do you know for sure? Maybe the OP wants to use this thing with 3
    >> known researchers working on a cluster that is not even visible to the
    >> outside world. In such a setup the model the OP suggested is a perfectly
    >> reasonable one. I say this because I often work in such an environment
    >> and security is never an issue for us. And I find it always amusing that
    >> whenever I outline our code to a non-scientist programmer they always
    >> run away in shock and never talk to us again

    >
    > You might be a great scientist, but perhaps you should pay attention to
    > the experts on programming who tell you that this is opening a potential
    > security hole in your system.
    >
    > No, it's not a "perfectly reasonable" tactic. It's a risky tactic that
    > only works because the environment you use it in is so limited and the
    > users so trusted. Can you guarantee that will never change? If not, then
    > you should rethink your tactic of using exec.
    >
    > Besides, as a general rule, exec is around an order of magnitude slower
    > than running code directly. If performance matters at all, you are better
    > off to try to find an alternative to exec.
    >
    >
    >> Nevertheless our code works perfectly for our purposes.

    >
    > Until the day that some manager decides that it would be great to make
    > your code into a service available over the Internet, or until one of the
    > other scientists decides that he really needs to access it from home, or
    > somebody pastes the wrong text into the application and it blows up in
    > your face... it's not just malice you need to be careful of, but also
    > accidents.
    >
    > The history of computing is full of systems that were designed with no
    > security because it wasn't needed, until it was needed, but it was too
    > late by then.
    >
    > There's no need, or at least very little need, to put locks on the
    > internal doors of your house, because we're not in the habit of taking
    > internal doors and turning them into outside doors. But code designed to
    > run inside your secure, safe network has a tendency to be re-purposed to
    > run in insecure, unsafe networks, usually by people who have forgotten,
    > or never knew, that they were opening up their system to code injection
    > attacks.
    >
    >
    >
    > --
    > Steven


    Steven, remember a few weeks ago when you tried to explain to me that
    the person who was storing windows administrative passwords using a
    40 byte xor cipher with the hardcoded password might not be doing
    something stupid because I didn't know what their threat model was?
    Yeah- what you just said is what I was trying to explain then.

    Geremy Condra
     
    geremy condra, Nov 10, 2009
    #8
  9. >>> This is a *really* bad idea.
    >>
    >> How do you know for sure? Maybe the OP wants to use this thing with 3
    >> known researchers working on a cluster that is not even visible to the
    >> outside world. In such a setup the model the OP suggested is a
    >> perfectly reasonable one. I say this because I often work in such an
    >> environment and security is never an issue for us. And I find it
    >> always amusing that whenever I outline our code to a non-scientist
    >> programmer they always run away in shock and never talk to us again :)
    >> Nevertheless our code works perfectly for our purposes.

    >
    > It is a bad idea because that's exactly why we now have a spam
    > problem. It _was_ a trusted environment once upon a time. Just check
    > your spam messages to see why ignoring security can lead to really bad
    > results.
    >
    > Do you know for sure that in say 3-5 years from now on your software
    > isn't released into the wild and then has no security at all?


    In my case, yes, I know for sure that the software I was talking about
    will only be used by my colleagues (3-4 people) and will only be used
    on our system. Why? Because the code is completely unportable and
    undocumented and was made to serve one purpose alone: to just work on
    our clusters which are not visible from the internet. And it serves
    this purpose great.

    In case we need to share this code, release it, modify it, etc, etc,
    we will think about all the security issues. But not until then.

    The point I'm trying to make is that of course I'm aware of the risks
    in our approach, the environment we are working in allows for these
    risks. In another situation I wouldn't use this type of approach. As a
    programmer I decide what solution to use in which environment and I
    intend to not over kill.

    No risk environment = security holes are okay.
    Risky environment = secure code from day one.

    Cheers,
    Daniel

    --
    Psss, psss, put it down! - http://www.cafepress.com/putitdown
     
    Daniel Fetchinson, Nov 10, 2009
    #9
  10. >>> This is a *really* bad idea.
    >>
    >> How do you know for sure? Maybe the OP wants to use this thing with 3
    >> known researchers working on a cluster that is not even visible to the
    >> outside world. In such a setup the model the OP suggested is a perfectly
    >> reasonable one. I say this because I often work in such an environment
    >> and security is never an issue for us. And I find it always amusing that
    >> whenever I outline our code to a non-scientist programmer they always
    >> run away in shock and never talk to us again

    >
    > You might be a great scientist, but perhaps you should pay attention to
    > the experts on programming who tell you that this is opening a potential
    > security hole in your system.


    Well, I'm completely aware of the potential security threats. It's not
    something I'm overlooking, rather, I'm taking them into account
    according to their real importance in our specific environment. And by
    the way, I'm not a great scientist :)

    However if the environment is such that the potential risks can not be
    exploited (not even in theory), because exactly 3 people have access
    to a machine and all of them are trustworthy and the clusters on which
    the code runs is not accessible from the internet, well, then the
    'security hole' which would be dangerous otherwise, is risk free in
    this case.

    > No, it's not a "perfectly reasonable" tactic.


    I believe it is.

    > It's a risky tactic that
    > only works because the environment you use it in is so limited and the
    > users so trusted.


    Exactly!

    > Can you guarantee that will never change?


    Yes. I will simply not release the code to anyone.

    > If not, then you should rethink your tactic of using exec.


    I agree.

    > Besides, as a general rule, exec is around an order of magnitude slower
    > than running code directly. If performance matters at all, you are better
    > off to try to find an alternative to exec.


    That is a good point, thanks. If we'll have performance issues, I'll
    remember this.


    >> Nevertheless our code works perfectly for our purposes.

    >
    > Until the day that some manager decides that it would be great to make
    > your code into a service available over the Internet, or until one of the
    > other scientists decides that he really needs to access it from home, or
    > somebody pastes the wrong text into the application and it blows up in
    > your face


    I agree. If any of those things would occur, our software would be
    pretty dangerous.

    > ... it's not just malice you need to be careful of, but also accidents.


    Agreed. If we mistype something (as suggested by others), well, it's
    our fault. We know what will happen, if we still do it, well, it's our
    fault, we'll fix it. Believe it or not, so far (after about 1.5 years
    of operation) there were no typos that created problems.

    > The history of computing is full of systems that were designed with no
    > security because it wasn't needed, until it was needed, but it was too
    > late by then.
    >
    > There's no need, or at least very little need, to put locks on the
    > internal doors of your house, because we're not in the habit of taking
    > internal doors and turning them into outside doors. But code designed to
    > run inside your secure, safe network has a tendency to be re-purposed to
    > run in insecure, unsafe networks, usually by people who have forgotten,
    > or never knew, that they were opening up their system to code injection
    > attacks.


    On general grounds, you are right, of course.

    My point is that hacking can still be a fun and easy-going activity
    when one writes code for himself (almost) without regards to security
    and nasty things like that creeping in from the outside. I'm the king
    in my castle, although I'm fully aware of the fact that my castle
    might be ugly from the outside :)

    Cheers,
    Daniel


    --
    Psss, psss, put it down! - http://www.cafepress.com/putitdown
     
    Daniel Fetchinson, Nov 10, 2009
    #10
  11. On Tue, 10 Nov 2009 12:28:49 -0500, geremy condra wrote:

    > Steven, remember a few weeks ago when you tried to explain to me that
    > the person who was storing windows administrative passwords using a 40
    > byte xor cipher with the hardcoded password might not be doing something
    > stupid because I didn't know what their threat model was? Yeah- what you
    > just said is what I was trying to explain then.


    No, I'm sure that wasn't me... perhaps some other Steven D'Aprano... from
    the Evil Dimension...

    *wink*

    Seriously, I'm not sure if I knew that the person was storing Windows
    admin passwords at the time. If I had, I probably would have agreed with
    you. But using a 40 byte xor cipher to obfuscate some strings in a game
    is perfectly valid -- not every locked box needs to be a safe with 18
    inch tempered steel walls.

    I can only repeat what I said to Daniel: can you guarantee that the nice
    safe, low-risk environment will never change? If not, then choose a more
    realistic threat model, and build the walls of your locked box
    accordingly.


    --
    Steven
     
    Steven D'Aprano, Nov 10, 2009
    #11
  12. > My point is that hacking can still be a fun and easy-going activity
    > when one writes code for himself (almost) without regards to security
    > and nasty things like that creeping in from the outside. I'm the king
    > in my castle, although I'm fully aware of the fact that my castle
    > might be ugly from the outside :)


    Which is a relevant statement in the context of the OP seeking advice on
    *secure ways* of executing code in a restricted environment in exactly
    what way?

    Diez
     
    Diez B. Roggisch, Nov 10, 2009
    #12
  13. >> My point is that hacking can still be a fun and easy-going activity
    >> when one writes code for himself (almost) without regards to security
    >> and nasty things like that creeping in from the outside. I'm the king
    >> in my castle, although I'm fully aware of the fact that my castle
    >> might be ugly from the outside :)

    >
    > Which is a relevant statement in the context of the OP seeking advice on
    > *secure ways* of executing code in a restricted environment in exactly
    > what way?


    Okay, I reread the original message and you are right, the OP did want
    restricted scope, so probably his environment is not completely risk
    free.

    Cheers,
    Daniel

    --
    Psss, psss, put it down! - http://www.cafepress.com/putitdown
     
    Daniel Fetchinson, Nov 10, 2009
    #13
  14. Cooch

    Ethan Furman Guest

    Daniel Fetchinson wrote:
    > I'm the king in my castle, although I'm fully aware of the fact that my castle
    > might be ugly from the outside :)


    +1 QOTW
     
    Ethan Furman, Nov 10, 2009
    #14
  15. Cooch

    Ethan Furman Guest

    Steven D'Aprano wrote:
    > I can only repeat what I said to Daniel: can you guarantee that the nice
    > safe, low-risk environment will never change? If not, then choose a more
    > realistic threat model, and build the walls of your locked box
    > accordingly.


    Seems to me you can't really *guarentee* anything, especially something
    as elusive as the distant future. Program for what your needs are, and
    document accordingly.

    ~Ethan~
     
    Ethan Furman, Nov 10, 2009
    #15
  16. On Tue, Nov 10, 2009 at 2:08 PM, Steven D'Aprano
    <> wrote:
    > On Tue, 10 Nov 2009 12:28:49 -0500, geremy condra wrote:
    >
    >> Steven, remember a few weeks ago when you tried to explain to me that
    >> the person who was storing windows administrative passwords using a 40
    >> byte xor cipher with the hardcoded password might not be doing something
    >> stupid because I didn't know what their threat model was? Yeah- what you
    >> just said is what I was trying to explain then.

    >
    > No, I'm sure that wasn't me... perhaps some other Steven D'Aprano... from
    > the Evil Dimension...
    >
    > *wink*


    I think I saw a mustache on him. Probably evil.

    > Seriously, I'm not sure if I knew that the person was storing Windows
    > admin passwords at the time. If I had, I probably would have agreed with
    > you. But using a 40 byte xor cipher to obfuscate some strings in a game
    > is perfectly valid -- not every locked box needs to be a safe with 18
    > inch tempered steel walls.


    Granted, and I am going to be able to give a very nice talk on how not
    to do cryptography partially as a result of that particularly egregious bit of
    silliness, so I guess I can't complain too much.

    > I can only repeat what I said to Daniel: can you guarantee that the nice
    > safe, low-risk environment will never change? If not, then choose a more
    > realistic threat model, and build the walls of your locked box
    > accordingly.


    Or, plan on becoming part of one of my presentations in a few years.
    Either way works for me.

    Geremy Condra
     
    geremy condra, Nov 10, 2009
    #16
  17. Cooch

    Aahz Guest

    In article <>,
    Cooch <> wrote:
    >
    >I want to implement such specific feature:
    >I have a server written in Python. I have a client written in C++. I
    >want to use Python as network protocol between them. I mean: client
    >send to server such string: "a = MyObject()", so object of this type
    >will appear in server. Any ideas how to simplify this implementation?
    >I make XML-RPC/SOAP server using twisted which just execute sended
    >string. But I don't know how to:
    >1. Restrict usage of some modules on client side (os, sys etc..)
    >2. Divide variables of different clients. Generally, I know that I
    >should use "exec .. in .. " construct, but don't know how to
    >distinguish between clients in twisted.


    What you want is a DSL -- domain-specific language. That might be a
    subset of Python that you parse yourself.
    --
    Aahz () <*> http://www.pythoncraft.com/

    [on old computer technologies and programmers] "Fancy tail fins on a
    brand new '59 Cadillac didn't mean throwing out a whole generation of
    mechanics who started with model As." --Andrew Dalke
     
    Aahz, Nov 15, 2009
    #17
    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. VisionSet

    OO network protocol

    VisionSet, Nov 13, 2005, in forum: Java
    Replies:
    6
    Views:
    443
    VisionSet
    Nov 14, 2005
  2. Mike Mimic
    Replies:
    5
    Views:
    431
    John Harrison
    May 7, 2004
  3. DaveC

    Network Protocol?

    DaveC, Jul 9, 2004, in forum: C++
    Replies:
    14
    Views:
    701
    Phlip
    Jul 10, 2004
  4. Laszlo Zsolt Nagy

    Developing a network protocol with Python

    Laszlo Zsolt Nagy, Dec 12, 2005, in forum: Python
    Replies:
    12
    Views:
    1,131
    Irmen de Jong
    Dec 15, 2005
  5. Erik
    Replies:
    7
    Views:
    624
    Joshua Cranmer
    Mar 27, 2008
Loading...

Share This Page