Python as network protocol

[Cooch]

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.

 

[Diez B. Roggisch]

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

 

[Daniel Fetchinson]

I want to implement such specific feature:
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

 

[Martin]

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

 

[Steven D'Aprano]

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.

 

[Grant Edwards]

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

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.

 

[Diez B. Roggisch]

Have you considered using pyro?

http://pyro.sourceforge.net/

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

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

 

[geremy condra]

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.



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, 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

 

[Daniel Fetchinson]

This is a *really* bad idea.

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

 

[Daniel Fetchinson]

This is a *really* bad idea.

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.

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

 

[Steven D'Aprano]

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.

 

[Diez B. Roggisch]

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

 

[Daniel Fetchinson]

My point is that hacking can still be a fun and easy-going activity

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

 

[Ethan Furman]

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]

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~

 

[geremy condra]

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

 

[Aahz]

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 ([email protected]) <*> 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