On 2016-04-07, Jon Ribbens wrote:
> I've put an example script here:
>
> https://github.com/jribbens/unsafe/blob/master/unsafe.py
>
> When run as a script, it will execute whatever Python code you pass it
> on stdin.
>
> If anyone can break it (by which I mean escape from the sandbox,
> not make
Paul Rubin writes:
> Lua is supposed to be easy to embed and sandbox. It might be
> interesting to write Python bindings for the Lua interpreter sometime.
Isn't this something similar to already existing
https://pypi.python.org/pypi/lupa/?
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò d
On Fri, 8 Apr 2016 12:25 am, Jon Ribbens wrote:
> On 2016-04-07, Chris Angelico wrote:
>> Options 1 and 2 are nastily restricted. Option 3 is likely broken, as
>> exception objects carry tracebacks and such.
>
> Everything you're saying here is assuming that we must not let the
> attacker see an
On Fri, 8 Apr 2016 01:18 am, Jon Ribbens wrote:
> No, actually absolutely no modules at all are safe to import directly.
> This is because the untrusted code might alter them
Good thinking! I never even thought of that.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Apr 7, 2016 at 11:35 AM, Jon Ribbens
wrote:
> Well, it entirely depends on how much you're trying to allow the
> sandboxed code to do. Most of the stuff in that script (e.g.
> _copy_module and safe versions of get/set/delattr, exec, and eval)
> I don't think is really necessary for most se
On 2016-04-07, Chris Angelico wrote:
> On Fri, Apr 8, 2016 at 3:20 AM, Jon Ribbens
> wrote:
>> On 2016-04-07, Random832 wrote:
>>> On Thu, Apr 7, 2016, at 08:13, Jon Ribbens wrote:
> All the obvious, and even not-so-obvious, attack tools are gone:
> eval, exec, getattr, type, __import__
On Fri, Apr 8, 2016 at 3:20 AM, Jon Ribbens
wrote:
> On 2016-04-07, Random832 wrote:
>> On Thu, Apr 7, 2016, at 08:13, Jon Ribbens wrote:
>>> > All the obvious, and even not-so-obvious, attack tools are gone:
>>> > eval, exec, getattr, type, __import__.
>>
>> We don't even need to take these away
On 2016-04-07, Random832 wrote:
> On Thu, Apr 7, 2016, at 08:13, Jon Ribbens wrote:
>> > All the obvious, and even not-so-obvious, attack tools are gone:
>> > eval, exec, getattr, type, __import__.
>
> We don't even need to take these away, per se.
>
> eval and exec could be replaced with function
On Fri, Apr 8, 2016 at 1:18 AM, Jon Ribbens
wrote:
> No, actually absolutely no modules at all are safe to import directly.
> This is because the untrusted code might alter them, and then the
> altered code would be used by the trusted main application. Trivial
> examples might include altering ha
On 2016-04-07, Chris Angelico wrote:
> On Thu, Apr 7, 2016 at 11:45 AM, Steven D'Aprano wrote:
>> And you would have to do something about the unfortunate matter that modules
>> have a reference to the unrestricted __builtins__:
>>
>> py> os.__builtins__['eval']
>>
>
> This *in itself* is blocke
On Thu, Apr 7, 2016, at 08:13, Jon Ribbens wrote:
> > All the obvious, and even not-so-obvious, attack tools are gone:
> > eval, exec, getattr, type, __import__.
We don't even need to take these away, per se.
eval and exec could be replaced with functions that perform the
evaluation with the same
On Thu, Apr 7, 2016, at 00:48, Steven D'Aprano wrote:
> Sure, but I'm just demonstrating that the unrestricted builtins are just
> one
> attribute lookup away. And as Chris points out, if you have (say) the os
> module, then:
>
> magic = os.sys.modules[
> ''.join(chr(i-1) for i in
> (96,
On 2016-04-07, Chris Angelico wrote:
> Options 1 and 2 are nastily restricted. Option 3 is likely broken, as
> exception objects carry tracebacks and such.
Everything you're saying here is assuming that we must not let the
attacker see any exception objects, but I don't understand why you're
assu
On Thu, Apr 7, 2016 at 10:13 PM, Jon Ribbens
wrote:
> It's true that I was using eval(), but I don't think that actually
> fundamentally changes the game. Almost exactly the same sanitisation
> method can be used to make exec() code safe. ("import" for example
> does not work because there is no "
On 2016-04-06, Steven D'Aprano wrote:
> On Wed, 6 Apr 2016 03:48 am, Chris Angelico wrote:
>> On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens
>> wrote:
>>> The received wisdom is that restricted code execution in Python is
>>> an insolubly hard problem, but it looks a bit like my 7-line example
>>> a
Jon Ribbens writes:
>> That string decodes to "__private".
> Yes, and? ... The namespace
> I was suggesting didn't provide access to any objects which have a
> 'get()' method which would access attributes.
I see, I forgot that getattr is a function, not an object method.
Though, now you've got th
On Thursday 07 April 2016 13:40, Random832 wrote:
> On Wed, Apr 6, 2016, at 21:45, Steven D'Aprano wrote:
>> And you would have to do something about the unfortunate matter that
>> modules
>> have a reference to the unrestricted __builtins__:
>>
>> py> os.__builtins__['eval']
>>
>
> Well, I tho
On Wed, Apr 6, 2016, at 21:45, Steven D'Aprano wrote:
> And you would have to do something about the unfortunate matter that
> modules
> have a reference to the unrestricted __builtins__:
>
> py> os.__builtins__['eval']
>
Well, I thought that the solution being discussed uses AST to generally
fo
On Thu, Apr 7, 2016 at 11:45 AM, Steven D'Aprano wrote:
> And you would have to do something about the unfortunate matter that modules
> have a reference to the unrestricted __builtins__:
>
> py> os.__builtins__['eval']
>
This *in itself* is blocked by the rule against leading-underscore
attribu
On Wed, 6 Apr 2016 11:14 pm, Random832 wrote:
> On Tue, Apr 5, 2016, at 21:43, Steven D'Aprano wrote:
>> As Zooko says, Guido's "best argument is that reducing usability (in
>> terms
>> of forbidding language features, especially module import) and reducing
>> the
>> usefulness of extant library c
On Wed, Apr 6, 2016, at 12:04, Chris Angelico wrote:
> On Thu, Apr 7, 2016 at 1:41 AM, Ian Kelly wrote:
> > type might also be a concern since it can be used to assemble
> > arbitrary classes.
>
> Sadly, this means denying the ability to interrogate an object for its
> type. And no, this won't do
On Wed, Apr 6, 2016 at 10:04 AM, Chris Angelico wrote:
> On Thu, Apr 7, 2016 at 1:41 AM, Ian Kelly wrote:
>> type might also be a concern since it can be used to assemble
>> arbitrary classes.
>
> Sadly, this means denying the ability to interrogate an object for its
> type. And no, this won't do
On Thu, Apr 7, 2016 at 1:41 AM, Ian Kelly wrote:
> type might also be a concern since it can be used to assemble
> arbitrary classes.
Sadly, this means denying the ability to interrogate an object for its
type. And no, this won't do:
def safe_type(obj): return type(obj)
because all you need is
On Tue, Apr 5, 2016 at 7:43 PM, Steven D'Aprano wrote:
> I think Jon is on the right approach here for restricting evaluation of
> evaluation, which is a nicely constrained and small subset of Python. He's
> not allowing unrestricted arbitrary code execution: he has a very
> restricted (too restri
On Tue, Apr 5, 2016, at 21:43, Steven D'Aprano wrote:
> As Zooko says, Guido's "best argument is that reducing usability (in
> terms
> of forbidding language features, especially module import) and reducing
> the
> usefulness of extant library code" would make the resulting interpreter
> too
> feeb
On Wed, Apr 6, 2016 at 11:43 AM, Steven D'Aprano wrote:
> Look at what you've done: you've restricted the entire world of Python down
> to, effectively, a calculator and a few string methods. That's not to say
> that a calculator and a few string methods won't be useful to someone, but
> the next
On Wed, 6 Apr 2016 03:48 am, Chris Angelico wrote:
> On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens
> wrote:
>> The received wisdom is that restricted code execution in Python is
>> an insolubly hard problem, but it looks a bit like my 7-line example
>> above disproves this theory,
Jon's 7-line ex
On 2016-04-05, Paul Rubin wrote:
> Jon Ribbens writes:
>>> isinstance(node, ast.Attribute) and node.attr.startswith("_")):
>>> raise ValueError("Access to private values is not allowed.")
>>> namespace = {"__builtins__": {"int": int, "str": str, "len": len}}
>
>> N
Jon Ribbens writes:
>> isinstance(node, ast.Attribute) and node.attr.startswith("_")):
>> raise ValueError("Access to private values is not allowed.")
>> namespace = {"__builtins__": {"int": int, "str": str, "len": len}}
> Nobody has any thoughts on this at all?
W
On Wed, Apr 6, 2016 at 4:50 AM, Jon Ribbens
wrote:
> On 2016-04-05, Chris Angelico wrote:
>> On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens
>> wrote:
>>> The received wisdom is that restricted code execution in Python is
>>> an insolubly hard problem, but it looks a bit like my 7-line example
>>> ab
On 2016-04-05, Jon Ribbens wrote:
> On 2016-04-05, Chris Angelico wrote:
>> Your code is a *lot* safer for using 'eval' rather than 'exec'.
>> Otherwise, you'd be easily exploited using exceptions, which carry a
>> ton of info.
>
> ... but all in attributes that don't start with "_", as far as I
On 2016-04-05, Chris Angelico wrote:
> You can also create objects of various types using literal/display
> syntax, and that might let you craft some weird construct that
> effectively access those attributes without actually having an
> attribute that starts with an underscore. (Think of "getattr
On 2016-04-05, Chris Angelico wrote:
> On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens
> wrote:
>> The received wisdom is that restricted code execution in Python is
>> an insolubly hard problem, but it looks a bit like my 7-line example
>> above disproves this theory, provided you choose carefully wh
On Wed, Apr 6, 2016 at 3:52 AM, Ian Kelly wrote:
> On Tue, Apr 5, 2016 at 11:48 AM, Chris Angelico wrote:
>> Your code is a *lot* safer for using 'eval' rather than 'exec'.
>> Otherwise, you'd be easily exploited using exceptions, which carry a
>> ton of info. But even so, I would not bet money (
On Tue, Apr 5, 2016 at 11:48 AM, Chris Angelico wrote:
> Your code is a *lot* safer for using 'eval' rather than 'exec'.
> Otherwise, you'd be easily exploited using exceptions, which carry a
> ton of info. But even so, I would not bet money (much less the
> security of my systems) on this being s
On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens
wrote:
> The received wisdom is that restricted code execution in Python is
> an insolubly hard problem, but it looks a bit like my 7-line example
> above disproves this theory, provided you choose carefully what you
> provide in your restricted __builti
On 2016-04-05, Chris Angelico wrote:
> On Wed, Apr 6, 2016 at 12:50 AM, Ian Kelly wrote:
>> Same here, although it looks to me like this approach could work. Or
>> I'm just not clever enough to see how it could be exploited.
>
> Having been bitten in the past (our test box was compromised by
> py
On 2016-04-05, Rustom Mody wrote:
> On Tuesday, April 5, 2016 at 7:19:39 PM UTC+5:30, Jon Ribbens wrote:
>> On 2016-04-03, Jon Ribbens wrote:
>> > I'd just like to say up front that this is more of a thought experiment
>> > than anything else, I don't have any plans to use this idea on any
>> > ge
On Wed, Apr 6, 2016 at 12:50 AM, Ian Kelly wrote:
> Same here, although it looks to me like this approach could work. Or
> I'm just not clever enough to see how it could be exploited.
Having been bitten in the past (our test box was compromised by
python-list white hats within 20 minutes of the i
On Tue, Apr 5, 2016 at 8:17 AM, Rustom Mody wrote:
> On Tuesday, April 5, 2016 at 7:19:39 PM UTC+5:30, Jon Ribbens wrote:
>> On 2016-04-03, Jon Ribbens wrote:
>> > I'd just like to say up front that this is more of a thought experiment
>> > than anything else, I don't have any plans to use this id
On Tuesday, April 5, 2016 at 7:19:39 PM UTC+5:30, Jon Ribbens wrote:
> On 2016-04-03, Jon Ribbens wrote:
> > I'd just like to say up front that this is more of a thought experiment
> > than anything else, I don't have any plans to use this idea on any
> > genuinely untrusted code. Apart from anythi
On 2016-04-03, Jon Ribbens wrote:
> I'd just like to say up front that this is more of a thought experiment
> than anything else, I don't have any plans to use this idea on any
> genuinely untrusted code. Apart from anything else, there's the
> denial-of-service issue.
>
> That said, is there any
42 matches
Mail list logo
