mysticgalaxies team mailing list archive

[Henrik Nilsson <henrik30000@xxxxxxxxx>]

of course, didn't intend to blame it on Python, those are intentional
functions, just that we don't happen to want them in Amethyst.
you seem quite knowledgable about sandboxing (or security in general), I
don't know that much myself.
Though I read that Python has some restriction functions, like r_eval,
however there is some way to exploit your way out of those so they were
recommended to avoid.
The approach that I used to implement it in Amethyst was rather to just
remove what's dangerous (by running del __builtins__.__dict__['file'] for
all dangerous builtins that we know of, including __import__, before running
any arbitrary code), do you think we could somehow set up a better sandbox
ourselves? (as opposed to r_eval which is known to be exploitable)

2009/5/27 Henrik Nilsson <henrik30000@xxxxxxxxx>

> of course, didn't intend to blame it on Python, those are intentional
> functions, just that we don't happen to want them in Amethyst.
> you seem quite knowledgable about sandboxing (or security in general), I
> don't know that much myself.
> Though I read that Python has some restriction functions, like r_eval,
> however there is some way to exploit your way out of those so they were
> recommended to avoid.
> The approach that I used to implement it in Amethyst was rather to just
> remove what's dangerous (by running del __builtins__.__dict__['file'] for
> all dangerous builtins that we know of, including __import__, before running
> any arbitrary code), do you think we could somehow set up a better sandbox
> ourselves? (as opposed to r_eval which is known to be exploitable)
>
>
> 2009/5/27 Ted Smith <teddks@xxxxxxxxx>
>
>> The security problem (as I see it) isn't about exploits in the actual
>> Python system, it's with executing untrusted code.
>>
>> The solution to executing untrusted code is to implement a MAC system in
>> the VM, so that by default programs are restricted to a given sandbox of
>> functionality. It should be possible to change those MACs if the user
>> requests, on a per-domain and per-script basis. At that point, the
>> problem is moved into Amethyst where we have to enforce those MACs. An
>> exploit in Amethyst would obviously result in the process being taken
>> over; it doesn't really matter what VM security measures we have at that
>> point.
>>
>> On Wed, 2009-05-27 at 17:45 +0200, Henrik Nilsson wrote:
>> > if we find that it is insecure we certainly should dump it, we don't
>> > want Amethyst to be exploitable.
>> > I've searched for Python exploits on milw0rm.com, but all the results
>> > there require that the os module is imported first, and we're not
>> > doing that (not ruling out that there might be other ways of course).
>> > I've been thinking and maybe we could post a challenge somewhere with
>> > a simple embedded Python application with the same security measures
>> > that we have and see if anyone can break it. (and we should also check
>> > if we can fix the hole that they find, if they find something)
>> > (and regarding our talk about Savannah, I guess it wouldn't hurt to
>> > register there and try things out, and if it isn't enough we'll just
>> > close it)
>> >
>> > 2009/5/27 Braden Walters <meoblast@xxxxxxx>
>> >         We don't necessarily have to dump Python, we just need to
>> >         evaluate
>> >         whether it is a smart idea, and then decide whether we will
>> >         stick with
>> >         it or go to something else. I took a quick look at Mozilla
>> >         Spidermonkey
>> >         (Javascript) but I'm not sure how powerful or extensible that
>> >         library
>> >         is.
>> >
>> >
>> >         On Wed, 2009-05-27 at 07:19 +0200, Henrik Nilsson wrote:
>> >         > We've already had to disable a few builtin functions, such
>> >         as file
>> >         > (which could open a local file for reading/writing), worth
>> >         noting is
>> >         > that also import is disabled, did you bring this up when you
>> >         asked,
>> >         > Braden?
>> >         > I think disabling import should save us from most security
>> >         headaches
>> >         > (other than builtin functions, but that's a relatively small
>> >         list)
>> >         > Though if we're gonna dump Python we'll have to find another
>> >         candidate
>> >         > quick, what do you say about Lua?
>> >         >
>> >         >
>> >         > Here's a list of languages that are good for embedding,
>> >         though without
>> >         > any consideration for security in arbitrary
>> >         > code,
>> >
>> http://en.wikipedia.org/wiki/Categorical_list_of_programming_languages
>> >         >
>> >         > 2009/5/27 Ted Smith <teddks@xxxxxxxxx>
>> >         >         Insecure how?
>> >         >
>> >         >
>> >         >         On Tue, 2009-05-26 at 19:33 -0400, Braden Walters
>> >         wrote:
>> >         >         > I asked the Python community about what they think
>> >         about
>> >         >         using Python
>> >         >         > for a project like Amethyst. They said it's WAY
>> >         too
>> >         >         insecure. I suppose
>> >         >         > it's best to go back now before we get too far
>> >         into a mess.
>> >         >         Since this
>> >         >         > is mostly for Rakhun, I'll have to talk to you in
>> >         IRC some
>> >         >         time about
>> >         >         > this.
>> >         >         >
>> >         >         >
>> >         >         > _______________________________________________
>> >         >         > Mailing list:
>> >         https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> >         >         > Post to     : mysticgalaxies@xxxxxxxxxxxxxxxxxxx
>> >         >         > Unsubscribe :
>> >         https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> >         >         > More help   : https://help.launchpad.net/ListHelp
>> >         >
>> >         >
>> >         >         _______________________________________________
>> >         >         Mailing list: https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> >         >         Post to     : mysticgalaxies@xxxxxxxxxxxxxxxxxxx
>> >         >         Unsubscribe : https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> >         >         More help   : https://help.launchpad.net/ListHelp
>> >         >
>> >         >
>> >         >
>> >         > _______________________________________________
>> >         > Mailing list: https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> >         > Post to     : mysticgalaxies@xxxxxxxxxxxxxxxxxxx
>> >         > Unsubscribe : https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> >         > More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>> >         _______________________________________________
>> >         Mailing list: https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> >         Post to     : mysticgalaxies@xxxxxxxxxxxxxxxxxxx
>> >         Unsubscribe : https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> >         More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> > Post to     : mysticgalaxies@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> Post to     : mysticgalaxies@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~mysticgalaxies<https://launchpad.net/%7Emysticgalaxies>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>