explains the important work taking place in the Shen group and what
we hope to achieve. Essentially we will be able to generate type-secure Python
programs which can be run independently within the Python environment.
We're asking Python programmers to support us in the production of this
techn
>> the same exploits. Think of a binary generated elsewhere (where
> "gcc" is available) and put into your environment.
That's pretty bad news :(
>
> I am convinced that 100 % security is impossible - and correspondingly
> would use a pragmatic approach: I would rely on OS level
> constraints (us
"Lakshmipathi.G" writes:
> Could you please share more info about creating raw binary executable
> and its potential
> problem.
In an earlier message, you reported to have banned "gcc" to
avoid "C" level exploits. A "raw binary executable" would allow
the same exploits. Think of a binary generate
> If you permit file I/O and anything that can spawn a process, it is
> possible to create a raw binary executable and trigger its execution.
> --
Yes,we permit file i/o with quota limits and spawning a process is
allowed upto a limit.
If I'm not wrong, we will be safe if user invokes sub
Hi -
Thanks for the response. Yes, we used OS features to
restrict the system user accounts.
We don't allow gcc - this helped us to avoid kernel exploits via C code like :
https://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=42827&forum=59
https://bugzilla.redhat.com/show_bu
"Lakshmipathi.G" writes:
> We have a server running a web-based terminal emulator (based on shellinabox
> for screen-casting check www.webminal.org) that allows users to learn
> simple bash commands. This Linux environment secured by things like quota,
> selinux,ulimit etc
>
> Now some users ar
Hi -
We have a server running a web-based terminal emulator (based on shellinabox
for screen-casting check www.webminal.org) that allows users to learn
simple bash commands. This Linux environment secured by things like quota,
selinux,ulimit etc
Now some users are requesting python access. How
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
"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
t; 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 postgr
"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.
>>
&g
"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
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 versi
42 matches
Mail list logo
