Hi List!
I was thinking about secure Python code execution, and I'd really
appreciate some comments from those who know Python better than I do.
I was thinking that maybe it could be possible to load and run untrusted
Python code, simply by loading it in a module with a modified version of
__builtins__. Without any reachable function that do unsafe operations,
code running from there shouldn't be able to do evil things.
Or? What would happen to `import'? Would it be possible to set a null
import path for a specific module. Are there any other ways to reach
modules/functions that would make this impossible (I don't seem to be
able to remember, but aren't there cross-references somewhere to the
defining modules of data passed to the code in the secure module)?
If this doesn't work, might there be some other way to run untrusted
code that I haven't thought of (apart from using O/S-specific stuff like
SECCOMD, of course).
Thank you very much for your time!
Fredrik Tolf
31  2340 
On Thu, 16 Nov 2006 04:02:58 +0100, Fredrik Tolf wrote:
Hi List!
I was thinking about secure Python code execution, and I'd really
appreciate some comments from those who know Python better than I do.
I was thinking that maybe it could be possible to load and run untrusted
Python code, simply by loading it in a module with a modified version of
__builtins__. Without any reachable function that do unsafe operations,
code running from there shouldn't be able to do evil things.
How would you prevent a Denial Of Service attack like this?
# don't try this at home kids! leave this to the professionals!
n = 10000**4
L = []
for i in range(n):
L.append(str(2L**n))
Here's an interesting one. Bug or deliberate attack?
def evens():
# iterator returning even numbers
i = 0
while True:
yield i
i += 2
# now get all the even numbers up to 15
L = [n for n in evens() if n < 15]
--
Steven D'Aprano
Steven D'Aprano wrote:
On Thu, 16 Nov 2006 04:02:58 +0100, Fredrik Tolf wrote:
>>Hi List!
I was thinking about secure Python code execution, and I'd really
appreciate some comments from those who know Python better than I do.
I was thinking that maybe it could be possible to load and run untrusted
Python code, simply by loading it in a module with a modified version of
__builtins__. Without any reachable function that do unsafe operations,
code running from there shouldn't be able to do evil things.
How would you prevent a Denial Of Service attack like this?
# don't try this at home kids! leave this to the professionals!
n = 10000**4
L = []
for i in range(n):
L.append(str(2L**n))
Here's an interesting one. Bug or deliberate attack?
def evens():
# iterator returning even numbers
i = 0
while True:
yield i
i += 2
# now get all the even numbers up to 15
L = [n for n in evens() if n < 15]
congraulations you have discovered loops and their misuse
timmy wrote:
congraulations you have discovered loops and their misuse
if you don't know what the phrase "denial of service attack" means, you
can always google for it.
</F>
On Thu, 16 Nov 2006 17:44:37 +1000, timmy wrote:
congraulations you have discovered loops and their misuse
Did you have a point in your utterly inane comment, or did you just want
to see your name on Usenet?
In any case, it isn't just "loops" that are dangerous.
print 2**512**512
No loop there, but it will operate as a lovely DoS attack if you run it.
The Original Poster is suggesting running UNTRUSTED code. That means you
have to assume that it will be actively hostile, but even if it isn't
deliberately hostile, there will be bugs which the developer can't control.
He wants to run this untrusted (hostile or buggy or both) code in an
environment where it can't do bad things. "Bad things" include Denial of
Service attacks. So, Timmy, let's hear your brilliant scheme for
preventing DoS attacks when running hostile code in Python.
--
Steven D'Aprano
Fredrik Tolf wrote:
If this doesn't work, might there be some other way to run untrusted
code that I haven't thought of (apart from using O/S-specific stuff like
SECCOMD, of course).
There was a module called rexec which tries to give you a restricted
environment for executing code. But it seems, that it is not maintained
anymore, because there were too much problems with it. It seems, that it is
very complicated to get a restricted execution environment without losing
too much of Pythons functionality.
One question is, what you want to achieve. As another posting in this thread
mentioned, you can't get around of denial of service attacks, even in
restricted or trusted environments. So I assume, that what you want is
something like a sandbox, where specific file actions (deleting files,
access to specific part of the FS at all) and some other things can be
restricted or forbidden. I think, this should be possible, even for some
DOS-Attacks (e.g. restricting the amount of memory that can be used by the
script, or the max stack size, depth of recursion limits etc.), but it is a
hard job to find all places, where code can break out of your sandbox. For
a full load of bad examples, simply have a look at JavaScript...
For a IMHO really good implementation of the sandbox idea, have a look at
the "safe interp" in Tcl. A short description (and by no mean complete) of
the safe interp is to run a second and completely independent interpreter
with all possibly dangerous commands completely removed and a
one-way-channel to inject commands and scripts into its evaluation loop
from the trusted interpreter. Depending on how much faith you have into the
untrusted script, you can selectively allow additional commands in the safe
interp or map common commands to other restricted or monitored versions of
them, which you implemented yourself inside your trusted environment. I do
not know, how complex it would be to do this in Python (since Tcl may look
a little old fashioned to some people but has some unique features that
helps especially with this kind of problem, such as having no keywords,
which makes it possible to change the semantics of even the most basic
constructs in the language from the scripting level), but I think it would
be a really useful feature for Python to have a sandbox mechanism to run
untrusted code.
Regards
Stephan
Fredrik Lundh wrote:
timmy wrote:
>congraulations you have discovered loops and their misuse
if you don't know what the phrase "denial of service attack" means, you
can always google for it.
</F>
maybe you should google "linux kernel limit" and you can prevent any
user/process maxing out your system
Steven D'Aprano wrote:
On Thu, 16 Nov 2006 17:44:37 +1000, timmy wrote:
>>congraulations you have discovered loops and their misuse
Did you have a point in your utterly inane comment, or did you just want
to see your name on Usenet?
In any case, it isn't just "loops" that are dangerous.
print 2**512**512
No loop there, but it will operate as a lovely DoS attack if you run it.
The Original Poster is suggesting running UNTRUSTED code. That means you
have to assume that it will be actively hostile, but even if it isn't
deliberately hostile, there will be bugs which the developer can't control.
He wants to run this untrusted (hostile or buggy or both) code in an
environment where it can't do bad things. "Bad things" include Denial of
Service attacks. So, Timmy, let's hear your brilliant scheme for
preventing DoS attacks when running hostile code in Python.
as posted before, linux kernel limit.
then you and your users can go as crazy as you want and you won't take
out your system.
maybe you should think a little more before going on the attack like that.
timmy wrote:
maybe you should google "linux kernel limit" and you can prevent any
user/process maxing out your system
one would have thought that the phrase "apart from OS-specific stuff"
might have meant that the OP wasn't asking for Linux-specific solutions.
</F>
timmy <"timothy at open-networks.net"wrote:
This sub-thread starts to become a flame-war, isn't it? Calm down, both of
you... No need to fight, when only some ideas for a technical question are
requested.
as posted before, linux kernel limit.
then you and your users can go as crazy as you want and you won't take
out your system.
The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.
Regards
Stephan
Fredrik Lundh wrote:
timmy wrote:
>maybe you should google "linux kernel limit" and you can prevent any
user/process maxing out your system
one would have thought that the phrase "apart from OS-specific stuff"
might have meant that the OP wasn't asking for Linux-specific solutions.
</F>
sorry i didn't see that.
cpu and memory limiting aren't specific to linux though, any NT system
can also do it.
the only effective way to prevent someone with access to a compiler
from performing a local dos on your system is use each os's resource
controls. there's no cross platform way to do this, since every system
has vastly different methods of memory and cpu time handling.
This looks like a case where he will just have to accept this as a trade
off (security is always a trade off)
Stephan Kuhagen wrote:
timmy <"timothy at open-networks.net"wrote:
This sub-thread starts to become a flame-war, isn't it? Calm down, both of
you... No need to fight, when only some ideas for a technical question are
requested.
i'm not fighting, sometimes i can be a little terse for that i aplogise.
>
>>as posted before, linux kernel limit.
then you and your users can go as crazy as you want and you won't take
out your system.
The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated.
idunno sounds like a lot of trouble to engineer a solution that has
already got a solution. all win NT systems have resource managment and i
imagine OS X would as well??
>
Regards
Stephan
timmy <"timothy at open-networks.net"wrote:
>count and limit the number of evaluation steps allowed for untrusted
script or methods in untrusted script as well as to limit the recursion
depth or memory to be allocated.
idunno sounds like a lot of trouble to engineer a solution that has
already got a solution. all win NT systems have resource managment and i
imagine OS X would as well??
Sounds very likely, but does not solve the problem. With resource management
on the OS level you can indeed set some important limits for untrusted
scripts, but there are at least two drawbacks, which come to my mind (and
maybe more, that I'm not aware of): 1. OS level can always only implement
the lowest common denominator of all OS resource managements to be platform
independent, which is a strong requirement, IMO. 2. If you want to exec a
untrusted script from inside a trusted interpreter giving it a sandbox,
then the sandbox has the same OS level restrictions as the first
interpreter (except when started in a separate process, which makes
communication between trusted and untrusted parts much more complicated).
Also you can't have such a fine grained control over the untrusted
execution environment at the OS level, e.g. limiting the recursion depth,
which is a very important limit for secure interpreters. Limiting the stack
on the OS level is for example no solution for this, because the byte code
may behave completely different on the stack (and regarding hidden internal
recursion) as what the toplevel Python code does (does anyone understand,
what I'm talking about... - I think I just reached the recurion limit of my
english capabilities), which means that you can't set deterministic
restrictions for untrusted code in a platform independent manner at the OS
level. - Managing all this in the interpreter would solve the problem, at
the cost of implementing lots of resource management code. A good sandbox
seems to be a real adventure with few survivors, as can be seen in the
JavaScript-world.
Regards
Stephan
Stephan Kuhagen wrote:
>
Sounds very likely, but does not solve the problem. With resource management
on the OS level you can indeed set some important limits for untrusted
scripts, but there are at least two drawbacks, which come to my mind (and
maybe more, that I'm not aware of): 1. OS level can always only implement
the lowest common denominator of all OS resource managements to be platform
independent, which is a strong requirement, IMO.
I think I understand what you intend to say here: that some kind of
Python sandbox relying on operating system facilities can only depend
on facilities implemented in all of the most interesting operating
systems (which I once referred to as "the big three", accompanied by
howls of protest/derision). Yet just as people like to say that
choosing a language is all about "choosing the right tool for the job",
shouldn't the choice of operating system be significant as well? If
you're running a "Try Python" Web site, as some people were doing a few
months ago, isn't it important to choose the right operating system as
part of the right complete environment, instead of having the
theoretical possibility of running it on something like RISC OS, yet
having someone take your site down within seconds anyway? I don't know
whether it's the same people who like to promote "how well Python plays
with everything else" who also demand totally cross-platform solutions
("if it doesn't work on Windows, we won't do it"), but if so, I'd be
interested in how they manage to reconcile these views.
[...]
A good sandbox seems to be a real adventure with few survivors, as can be seen in the
JavaScript-world.
Certainly, there are interesting directions to be taken with safe
execution at the language and runtime levels, but as technologies like
Java (in particular) have shown, it's possible for a project or a
company to find itself focusing heavily on such strategies at the cost
of readily available, mature technologies which might be good enough.
The emergence of virtualisation as a commodity technology would suggest
that sandboxing language runtimes isn't as fashionable as it was ten
years ago.
Paul
>
as posted before, linux kernel limit.
then you and your users can go as crazy as you want and you won't take
out your system.
maybe you should think a little more before going on the attack like that.
You should maybe read a little bit more when making bold statements about
the feasibility of a sandboxed _PYTHON_. The OP wrote:
"""
I was thinking that maybe it could be possible to load and run untrusted
Python code, simply by loading it in a module with a modified version of
__builtins__. Without any reachable function that do unsafe operations,
code running from there shouldn't be able to do evil things.
"""
At least to me - and I presume pretty much everybody except you in this
thread - this means that he is interested in executing arbitrary pieces of
python code inside the interpreter, which comes from e.g. players who
customize their in-game behavior of their avatars.
Now how exactly does linux (or any other resource limiting technique on any
OS) help here - killing the whole game server surely isn't a desirable
solution when one player goes berserk, might it be intentionally or not.
It is a recurring and pretty much understandable request on c.l.py to be
able to do so - sometimes it arises in the disguise of killable threads.
But unfortunately the solution doesn't seem to be as simple as one would
wish.
Diez
Paul Boddie wrote:
>implement the lowest common denominator of all OS resource managements to
be platform independent, which is a strong requirement, IMO.
I think I understand what you intend to say here: that some kind of
Python sandbox relying on operating system facilities can only depend
on facilities implemented in all of the most interesting operating
systems (which I once referred to as "the big three", accompanied by
howls of protest/derision
Oberon, Plan 9 and AmigaOS...? ;-)
). Yet just as people like to say that
choosing a language is all about "choosing the right tool for the job",
shouldn't the choice of operating system be significant as well?
Yes, it should. But it isn't most times, I think. Often you have the
situation to run a certain app e.g. on a OS that you can't simply exchange
to your needs, for example the game server you mentioned, if this should
run on an external host which is not maintained by you.
Personally I would always prefer an OS independent solution, because it
makes you more flexible. Some OS may be a good choice at a given time, but
after you app has grown up, you may come to the decision to change the OS
for some reason, but can't because you app depends on some of its specific
features. Especially for apps written in a scripting language I would try
to avoid that.
If
you're running a "Try Python" Web site, as some people were doing a few
months ago, isn't it important to choose the right operating system as
part of the right complete environment, instead of having the
theoretical possibility of running it on something like RISC OS, yet
having someone take your site down within seconds anyway? I don't know
whether it's the same people who like to promote "how well Python plays
with everything else" who also demand totally cross-platform solutions
("if it doesn't work on Windows, we won't do it"), but if so, I'd be
interested in how they manage to reconcile these views.
I'm afraid, we can't have a perfect world... But as I stated in another
posting before, I think it is possible, to get a secure execution
environment in a platform independent manner. The Tcl people did it and
since I made myself already very unpopular at c.l.tcl by requesting some of
Pythons goods for Tcl, I can do the same here by requesting some of Tcls
good inventions for Python... ;-)
The emergence of virtualisation as a commodity technology would suggest
that sandboxing language runtimes isn't as fashionable as it was ten
years ago.
Virtual environments are a good choice for some of the tasks that were done
with sandboxes in the past. But I'm afraid, that they are too huge for many
problems. Imagine running an instance of a virtual machine on a mobile
phone, or needing to execute some hundreds of them in parallel on a game
server (or CGI) which itself runs on a virtual host at your webhoster, and
of course none of them should be able to kill it's neighbours, so all of
them need their own VM... phiu, that would need a really big iron. So the
the idea of VMs _is_ a good one for certain situations, but the need for
secure execution environments inside an interpreter remains.
Regards
Stephan
Diez B. Roggisch wrote:
>
[Multiplayer game servers]
Now how exactly does linux (or any other resource limiting technique on any
OS) help here - killing the whole game server surely isn't a desirable
solution when one player goes berserk, might it be intentionally or not.
A significant issue is the architecture of the server itself. Is a
per-process solution acceptable or must everything happen in the same
process with lots of threads (or microthreads)? Of course, there are
games using lots of microthreads, although I'm not sure whether they
also use lots of processes, too, and it has been asserted that having
lots of operating system threads or processes is just too resource
intensive, but I think it's especially worth considering the nature of
the platform you're using and what it offers.
Presumably, the original idea with UNIX-based systems was that you'd
employ lots of processes in order to serve lots of customers, players,
and so on, and there were companies like Internet service providers
using precisely that one process per customer model in a naive fashion
(until they exceeded the limit on simultaneous process identifiers in
one particular case, I believe). Subsequent work focusing on throwing
lots of threads into a single server-side container and then trying to
isolate them from each other, all whilst running the container on a
UNIX variant - a classic Java architectural pattern - seems like a
curious distraction when one considers the strong portfolio of
appropriate and readily available technologies that are left unused in
the operating system of the deployment environment concerned.
It is a recurring and pretty much understandable request on c.l.py to be
able to do so - sometimes it arises in the disguise of killable threads.
But unfortunately the solution doesn't seem to be as simple as one would
wish.
And this is where the hot topics collide: people want performant
multitasking with lots of shared state (the global interpreter lock
controversy) together with sandboxing so that the individual threads
can't access most of that shared state (the restricted execution
controversy). But it's like using a trip to meet the neighbours to
justify a mission to the moon: you can visit the neighbours at a much
lower cost with the vehicles you already have. I hear that various
operating systems support better interprocess communication these days,
but then we meet the third hot topic: why won't it work on Windows?
Something has to give.
Paul
A significant issue is the architecture of the server itself. Is a
per-process solution acceptable or must everything happen in the same
process with lots of threads (or microthreads)? Of course, there are
games using lots of microthreads, although I'm not sure whether they
also use lots of processes, too, and it has been asserted that having
lots of operating system threads or processes is just too resource
intensive, but I think it's especially worth considering the nature of
the platform you're using and what it offers.
AFAIK most engines today are only single-threaded. A big grief for all those
dual-core owners out there.
And having thousands of players is common - spawning a process for each of
them certainly too resource-consuming.
AFAIK stackless python was initially financially supported by a
game-company. So I guess that shows us pretty much what games (at least)
are after: low-profile in-process threads, fine-grained controllable.
Diez
Diez B. Roggisch wrote:
>>as posted before, linux kernel limit.
then you and your users can go as crazy as you want and you won't take
out your system.
maybe you should think a little more before going on the attack like that.
You should maybe read a little bit more when making bold statements about
the feasibility of a sandboxed _PYTHON_. The OP wrote:
there is nothing preventing you putting limits on the resources each
process uses, on just about any modern day OS
At least to me - and I presume pretty much everybody except you in this
thread -
Oh no i understand perfectly what he wants, i merely suggest a simple OS
based solution.
this means that he is interested in executing arbitrary pieces of
python code inside the interpreter, which comes from e.g. players who
customize their in-game behavior of their avatars.
Now how exactly does linux (or any other resource limiting technique on any
OS) help here - killing the whole game server surely isn't a desirable
solution when one player goes berserk, might it be intentionally or not.
resource managment does not kill anything it merely prevents one process
running away and consuming the whole server. this is EXACTLY what he is
afraid of.
if he intends on running arbitrary code then i suggest he spawns each
one as a seperate thread with a spefic name and merely set limits on all
processes named X. that way he can run any whacky code he wants safely
inside those processes without fear of any one of them crashing the
server. I know it can be done under any of the nix's, I'm not sure how
to do so under windows, but it could probably be done.
>
It is a recurring and pretty much understandable request on c.l.py to be
able to do so - sometimes it arises in the disguise of killable threads.
But unfortunately the solution doesn't seem to be as simple as one would
wish.
i can understand people wanting an application based cross platform
solution to this, but i'm yet to see anything practicle hence i suggest
and OS based solution.
>
Diez
Paul Boddie wrote:
Diez B. Roggisch wrote:
[Multiplayer game servers]
>>Now how exactly does linux (or any other resource limiting technique on any
OS) help here - killing the whole game server surely isn't a desirable
solution when one player goes berserk, might it be intentionally or not.
And this is where the hot topics collide: people want performant
multitasking with lots of shared state (the global interpreter lock
controversy) together with sandboxing so that the individual threads
can't access most of that shared state (the restricted execution
controversy).
i'm not talking about sandboxing, that's a whole different kettle of
fish. i'm talking about resource managment options you can set in for
instance, the linux kernel.
you can limit the cpu and memory a process uses while still allowing it
the same access it would have outside of a sandbox. that way if any
clever monkeys try to dos you they merely consume their alloted quota.
timmy wrote:
Paul Boddie wrote:
Diez B. Roggisch wrote:
[Re-adding material...]
>At least to me - and I presume pretty much everybody except you in this
thread - this means that he is interested in executing arbitrary pieces of
python code inside the interpreter, which comes from e.g. players who
customize their in-game behavior of their avatars.
Here is where the issue of sandboxing is indirectly introduced into the
discussion.
>Now how exactly does linux (or any other resource limiting technique on any
OS) help here - killing the whole game server surely isn't a desirable
solution when one player goes berserk, might it be intentionally or not.
And this is where the hot topics collide: people want performant
multitasking with lots of shared state (the global interpreter lock
controversy) together with sandboxing so that the individual threads
can't access most of that shared state (the restricted execution
controversy).
i'm not talking about sandboxing, that's a whole different kettle of
fish. i'm talking about resource managment options you can set in for
instance, the linux kernel.
Yes, I know. I was merely covering related concepts of relevance
introduced earlier in the discussion (see above). In any case, if you
only have control over resource limits on execution contexts at the
operating system process level, yet your server architecture is
entirely based on a single process with many (micro)threads, then
you've got to consider the problem of restricting their
behaviour/consumption using the facilities available to you, most
likely by considering other server architectures. This, I argue, is
perfectly reasonable in order to solve both issues being discussed
using operating system facilities.
you can limit the cpu and memory a process uses while still allowing it
the same access it would have outside of a sandbox. that way if any
clever monkeys try to dos you they merely consume their alloted quota.
Indeed.
Paul
"Stephan Kuhagen" <no****@domain.tldwrote:
The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.
I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.
- Hendrik
"Stephan Kuhagen" <no****@domain.tldwrote:
The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.
I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.
- Hendrik
"Stephan Kuhagen" <no****@domain.tldwrote:
The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.
I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.
- Hendrik
"Stephan Kuhagen" <no****@domain.tldwrote:
The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.
I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.
- Hendrik
Hendrik van Rooyen wrote:
I seem to recall previous discussion on this group about a thing called
the bastion module,
and that it was deprecated. Not sure if it has any relevance.
Never heard about it, maybe it's worth a look for the OP.
Stephan
Stephan Kuhagen wrote:
Never heard about it, maybe it's worth a look for the OP.
$ more Misc/HISTORY
...
What's New in Python 2.3 alpha 2?
=================================
*Release date: 19-Feb-2003*
...
- Bastion.py and rexec.py are disabled. These modules are not safe in
Python 2.2 or 2.3.
historical references: http://effbot.org/librarybook/rexec.htm http://effbot.org/librarybook/bastion.htm
</F>
"Stephan Kuhagen" <no****@domain.tldwrote:
The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.
I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.
- Hendrik
Hendrik van Rooyen wrote:
"Stephan Kuhagen" <no****@domain.tldwrote:
>The problem with linux kernel limits are, that they won't work really good
on MacOSX and Windows... OTOH the idea is the right one, but the effect can
be achieved inside of Python. Since Python does byte compile the code and
the interpreter evaluates each byte code token in one evaluation step. The
interpreter could be extended for such usecases to count and limit the
number of evaluation steps allowed for untrusted script or methods in
untrusted script as well as to limit the recursion depth or memory to be
allocated. All those limits are managed by the interpreter for script code
and hence can be limited for untrusted code by the interpreter. This also
does not really make DoS impossible (what about C extensions? - maybe
restricting "import"?). - As I said before in this thread, making a sandbox
really secure is a hard job, and may need some serious changes in the
Python interpreter, but AFAIK from Tcl, it is possible - and would be nice
to have.
I seem to recall previous discussion on this group about a thing called the
bastion module,
and that it was deprecated. Not sure if it has any relevance.
Anyone with an interest in secure Python should take a look at what
Brett Cannon is doing in his postgraduate work. There have been some
discussions on the python-dev list.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
"Hendrik van Rooyen" <ma**@microcorp.co.zawrote - 5 times - must be record for
stupidity...
sorry about this - the message was stuck in my outbox for some reason, and I hit
the send key multiple times, not noticing that it was in fact being sent...
- Hendrik
Steve Holden wrote:
Anyone with an interest in secure Python should take a look at what
Brett Cannon is doing in his postgraduate work. There have been some
discussions on the python-dev list.
Can you some links to his work, the discussions or some other starting
point?
Stephan
Stephan Kuhagen wrote:
Steve Holden wrote:
Anyone with an interest in secure Python should take a look at what
Brett Cannon is doing in his postgraduate work. There have been some
discussions on the python-dev list.
Can you some links to his work, the discussions or some other starting
point?
ok, here's how you can google python-dev. cut/paste into the box
"site:mail.python.org/pipermail/python-dev/ brett cannon sandbox" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: d z e k y l |
last post by:
Hello,
I'd like to write a small backup utility in Python, which would take
advantage of Secure FTP to upload backup archives. Is there a library
implementing SFTP in Python (something like...
|
by: PiedmontBiz |
last post by:
Listening to National Public Radio while reading comp.lang.python. What a life!
I just heard a piece on NPR about the security failures of an electronic voting
system being developed. I know a...
|
by: Calvin |
last post by:
Hi All,
Could someone tell me just how secure Python is if compiled to an exe? Is it
more or less secure than using some other language?
Thanks
|
by: Boris Genc |
last post by:
Hi everybody.
I was wandering is there a method or a function already implemented in
python that supports secure deletion of data?
I'm interested in something which is able to securely wipe data...
|
by: andrew blah |
last post by:
Hello
I have recently released catchmail - a free (BSD license) open source
Python utility www.users.bigpond.net.au/mysite/catchmail.htm
This script processes in and outbound emails and stores...
|
by: jiba |
last post by:
Hi all,
I'm currently working on a secure Pickle-like module, Cerealizer,
http://home.gna.org/oomadness/en/cerealizer/index.html
Cerealizer has a pickle-like interface (load, dump, __getstate__,...
|
by: Laszlo Nagy |
last post by:
Hello,
I'm trying to create a simple XMLRPC server and a client. It is a small
application, but the connection needs to be secure. I would like the
client to be as thin as possible. Ideally, the...
|
by: Daniel Crespo |
last post by:
Hello everybody,
I'm trying to implement a secure xmlrpc server with basis on
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496786 recipe.
The thing that I'm concerned about is how can...
|
by: walterbyrd |
last post by:
I honestly don't know. But, I have seen articles and posts about how
PHP is terribly insecure. I don't usually see comparisons to other
common web languages.
I think the big vulnerablity is...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
