Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python as network protocol

Reply
Thread Tools

Python as network protocol

 
 
Cooch
Guest
Posts: n/a
 
      11-10-2009
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.
 
Reply With Quote
 
 
 
 
Diez B. Roggisch
Guest
Posts: n/a
 
      11-10-2009
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
 
Reply With Quote
 
 
 
 
Daniel Fetchinson
Guest
Posts: n/a
 
      11-10-2009
>> 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
 
Reply With Quote
 
Martin
Guest
Posts: n/a
 
      11-10-2009
On Tue, Nov 10, 2009 at 16:31, Daniel Fetchinson
<(E-Mail Removed)> 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
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-10-2009
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
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      11-10-2009
On 2009-11-10, Steven D'Aprano <(E-Mail Removed)> 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
 
Reply With Quote
 
Diez B. Roggisch
Guest
Posts: n/a
 
      11-10-2009
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
 
Reply With Quote
 
geremy condra
Guest
Posts: n/a
 
      11-10-2009
On Tue, Nov 10, 2009 at 10:56 AM, Steven D'Aprano
<(E-Mail Removed)> 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
 
Reply With Quote
 
Daniel Fetchinson
Guest
Posts: n/a
 
      11-10-2009
>>> 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
 
Reply With Quote
 
Daniel Fetchinson
Guest
Posts: n/a
 
      11-10-2009
>>> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Developing a network protocol with Python Laszlo Zsolt Nagy Python 12 12-15-2005 07:42 PM
wireless network protocol 802.11g+ =?Utf-8?B?QXJjYW5nZWw=?= Wireless Networking 1 05-06-2005 01:23 PM
Protocol Chart - Learn how to use a Protocol Analyzer news.comcast.giganews.com Wireless Networking 0 08-21-2004 04:35 PM
When i try to implement a server program giving UDP as protocol , it works fine , but if the same code is executed with TCP as protocol option, it gives an error. Tompyna Perl Misc 4 02-17-2004 06:51 PM
APC Network Management Cards Network Time Protocol Support NOT! Ed M Cisco 2 11-19-2003 07:57 PM



Advertisments