On 8/21/10 5:56 PM, Gregory Ewing wrote:
> Stephen Hansen wrote:
>
>> Me, I'm going to go farther on my own installation and kill import
>> entirely, and do a sort of require() which returns a special proxied
>> version of an imported module
>
> Note that you can install an __import__ function in
Stephen Hansen wrote:
Me, I'm going to go farther on my own installation and kill import
entirely, and do a sort of require() which returns a special proxied
version of an imported module
Note that you can install an __import__ function in the
builtins to provide this kind of functionality whi
On 8/16/10 7:01 AM, Roland Koebler wrote:
> On Sat, Aug 14, 2010 at 08:01:00PM -0700, Stephen Hansen wrote:
>>> As you can see, black listing isn't the best approach here.
>>
>> But I have a two pronged strategy: the black list is only half of the
>> equation. One, I'm blacklisting all the meta fun
On Sat, Aug 14, 2010 at 08:01:00PM -0700, Stephen Hansen wrote:
> > As you can see, black listing isn't the best approach here.
>
> But I have a two pronged strategy: the black list is only half of the
> equation. One, I'm blacklisting all the meta functions out of builtins.
But blacklists are *ne
On Sat, Aug 14, 2010 at 07:54:11PM -0700, Stephen Hansen wrote:
> How are you implementing refusing-names-beginning-with-underscore, out
> of curiosity?
I compile the expressions and look into co_names, e.g.:
>>> expr = "0 .__class__"
>>> c=compile(expr,"","eval")
>>> c.co_names
('__class__
On Aug 14, 1:37 am, Stephen Hansen wrote:
> Can you think of a way out of such a sandbox? A way to access disallowed
> stuff, not a way to DOS.
Hi, I have strange idea :): use Google Apps.
You'll need prepare some interfaces for your apps (for example via
WebServices)
Maybe it is wrong way, maybe
In message , Stephen
Hansen wrote:
> On 8/14/10 2:25 PM, Cameron Simpson wrote:
>
>> Ok, what about this: run the untrusted code in a separate process,
>> if necessary running as a user with different privileges.
>
> Way too much overhead by a really significant margin: I need to do many,
> many
On Sat, Aug 14, 2010 at 8:18 PM, Stephen Hansen
wrote:
> On 8/14/10 8:11 PM, geremy condra wrote:
>> cpulimit or a cgroups container can both be easy solutions here,
>> depending on your exact needs.
>
> Hmm! I wasn't aware of those, I'll check that out. Thanks.
Np. I wrote a set of cgroups bindi
On 8/14/10 8:11 PM, geremy condra wrote:
> cpulimit or a cgroups container can both be easy solutions here,
> depending on your exact needs.
Hmm! I wasn't aware of those, I'll check that out. Thanks.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT)
On Sat, Aug 14, 2010 at 8:07 PM, Stephen Hansen
wrote:
> On 8/14/10 5:09 PM, Steven D'Aprano wrote:
>>> My worst case
>>> fall-back plan is to embed /another/ language (be it Lua or JavaScript
>>> through V8) and offer it a very limited environment. But I don't want to
>>> do that (and considering
On 8/14/10 5:09 PM, Steven D'Aprano wrote:
>> My worst case
>> fall-back plan is to embed /another/ language (be it Lua or JavaScript
>> through V8) and offer it a very limited environment. But I don't want to
>> do that (and considering I solved the while True: pass problem last
>> night, I'm pret
On 8/14/10 5:36 PM, Christian Heimes wrote:
>> For example, when you go to save your bit of code, it will go in and if
>> it finds __ anywhere in the text it just replaces it with xx. And, since
>> getattr is not available, '_' + '_' won't get you anywhere.
>
> That's not as secure as you might th
On 8/14/10 4:24 PM, Roland Koebler wrote:
> You can find some documentation at
> http://simple-is-better.org/template/pyratemp.html#evaluation,
> and the pseudo-sandbox itself in my template-engine, class
> "EvalPseudoSandbox" on the website above.
> (Please write me if you have any comments.)
How
On 8/14/10 2:25 PM, Cameron Simpson wrote:
> Ok, what about this: run the untrusted code in a separate process,
> if necessary running as a user with different privileges.
Way too much overhead by a really significant margin: I need to do many,
many, many, many, many very short (often very *very*
On 8/14/10 5:06 PM, Steven D'Aprano wrote:
> On Sun, 15 Aug 2010 01:24:00 +0200, Roland Koebler wrote:
>
>> I had the same problem, and so I created a "pseudo-sandbox" for
>> embedding Python in templates. This "pseudo-sandbox" creates a
>> restricted Python environment, where only whitelisted fun
On Sun, Aug 15, 2010 at 12:06:35AM +, Steven D'Aprano wrote:
> Hmmm... is that meant just as an illustration of a general technique, or
> do you actually have something against the class of 0?
It's a short illustration; 0 .__class__ itself is harmless, but e.g.
0 .__class__.__base__.__subclass
> For example, when you go to save your bit of code, it will go in and if
> it finds __ anywhere in the text it just replaces it with xx. And, since
> getattr is not available, '_' + '_' won't get you anywhere.
That's not as secure as you might think. First of all you can write "_"
in more way tha
On Sat, 14 Aug 2010 12:56:45 -0700, Stephen Hansen wrote:
>> I suggest that if the untrusted code is only supposed to be simple and
>> limited, you would be best off to write your own "mini-language" using
>> Python syntax.
>
> I considered it and rejected it. The return from the effort required
On Sun, 15 Aug 2010 01:24:00 +0200, Roland Koebler wrote:
> I had the same problem, and so I created a "pseudo-sandbox" for
> embedding Python in templates. This "pseudo-sandbox" creates a
> restricted Python environment, where only whitelisted functions/classes
> are allowed. Additionally, it pre
Hi,
> I know all this -- but its not relevant really, I think. I'm not trying
> to create a safe yet relatively complete or functional Python. All those
> efforts to sandbox Python fail because of the incredible dynamic nature
> of the language has lots of enticing little holes in it. But I'm not
On Sat, Aug 14, 2010 at 12:56 PM, Stephen Hansen
wrote:
> On 8/13/10 8:04 PM, Steven D'Aprano wrote:
>> On Fri, 13 Aug 2010 16:37:40 -0700, Stephen Hansen wrote:
>>
>>> Howdy-ho.
>>>
>>> So, I'm working on a project which embeds Python into a bigger system to
>>> provide extensibility. In this pro
On 14Aug2010 12:56, Stephen Hansen wrote:
| On 8/13/10 8:04 PM, Steven D'Aprano wrote:
| > On Fri, 13 Aug 2010 16:37:40 -0700, Stephen Hansen wrote:
| >> So, I'm working on a project which embeds Python into a bigger system to
| >> provide extensibility. In this project, there's basically two type
On 8/13/10 8:04 PM, Steven D'Aprano wrote:
> On Fri, 13 Aug 2010 16:37:40 -0700, Stephen Hansen wrote:
>
>> Howdy-ho.
>>
>> So, I'm working on a project which embeds Python into a bigger system to
>> provide extensibility. In this project, there's basically two types of
>> people who will be enter
On Fri, 13 Aug 2010 16:37:40 -0700, Stephen Hansen wrote:
> Howdy-ho.
>
> So, I'm working on a project which embeds Python into a bigger system to
> provide extensibility. In this project, there's basically two types of
> people who will be entering python code.
>
> The trusted folks, who write
On 8/13/10 4:57 PM, geremy condra wrote:
> You may want to check out repy- they use it in the Seattle restricted
> execution environment, and some pretty smart people claim it has
> decent security properties. Here's a summary of some of the things
> they don't allow:
>
> https://seattle.cs.washin
On Fri, Aug 13, 2010 at 4:37 PM, Stephen Hansen
wrote:
> Howdy-ho.
>
> So, I'm working on a project which embeds Python into a bigger system to
> provide extensibility. In this project, there's basically two types of
> people who will be entering python code.
>
> The trusted folks, who write code
Howdy-ho.
So, I'm working on a project which embeds Python into a bigger system to
provide extensibility. In this project, there's basically two types of
people who will be entering python code.
The trusted folks, who write code which are in files, and which can do
anything.
The untrusted folks,
27 matches
Mail list logo
