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
--
http:/
"Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote - 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
--
http://mail.python.org/mailman/lis
Hendrik van Rooyen wrote:
> "Stephan Kuhagen" <[EMAIL PROTECTED]> wrote:
>
>
>> 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
"Stephan Kuhagen" <[EMAIL PROTECTED]> wrote:
> 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 eva
On Thu, 2006-11-16 at 08:43 +0200, Hendrik van Rooyen wrote:
> "Fredrik Tolf" <[EMAIL PROTECTED]> 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 reacha
krishnakant Mane wrote:
> I need to use python for a very mission critical project. may be I
> will also use zope.
> so I will like to know how far I can trust python for security in its
> absolute (platform independent ) sence?
> I mean running unwanted code at run-time etc.
If you want a secure
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
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
--
http://mail.python.org/mailman/listin
"Stephan Kuhagen" <[EMAIL PROTECTED]> wrote:
> 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 eva
"Stephan Kuhagen" <[EMAIL PROTECTED]> wrote:
> 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 eva
"Stephan Kuhagen" <[EMAIL PROTECTED]> wrote:
> 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 eva
"Stephan Kuhagen" <[EMAIL PROTECTED]> wrote:
> 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 eva
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
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 intention
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
> 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
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 iss
after reading all the mails on this thread, I have the following observations.
I am relatively new to python at its development side but very old as
far as using python is concerned.
firstly, talking about gnu/linux there is no question about security.
python, if at all it is non-secure wont harm a
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
>
> 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 fe
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 le
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
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 t
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 solut
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 yo
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.
--
http://mail.python.org/
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
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.
>
>
>
maybe you should google "linux kernel limit" and you can prevent any
user/proces
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
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 the
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.
--
http://mail.python.org/mailman/listinfo/python-list
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 loa
"Fredrik Tolf" <[EMAIL PROTECTED]> 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 shoul
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 c
34 matches
Mail list logo
