mysticgalaxies team mailing list archive
-
mysticgalaxies team
-
Mailing list archive
-
Message #00023
Re: Python :(
Please just send to the list, to avoid people getting duplicate
messages.
We don't need to remove anything, we just need to control what AAF
script has access to. A good way to do that would be to override the
builtins that communicate with the outside world with our own versions
that check callers against the MAC's first.
On Wed, 2009-05-27 at 21:44 +0200, Henrik Nilsson wrote:
> 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
> > > > Post to :
> mysticgalaxies@xxxxxxxxxxxxxxxxxxx
> > > > Unsubscribe :
> > https://launchpad.net/~mysticgalaxies
> > > > More help :
> https://help.launchpad.net/ListHelp
> > >
> > >
> > >
> _______________________________________________
> > > Mailing list:
> https://launchpad.net/~mysticgalaxies
> > > Post to :
> mysticgalaxies@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe :
> https://launchpad.net/~mysticgalaxies
> > > More help :
> https://help.launchpad.net/ListHelp
> > >
> > >
> > >
> > >
> _______________________________________________
> > > Mailing list:
> https://launchpad.net/~mysticgalaxies
> > > Post to :
> mysticgalaxies@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe :
> https://launchpad.net/~mysticgalaxies
> > > More help :
> https://help.launchpad.net/ListHelp
> >
> >
> >
> _______________________________________________
> > Mailing list:
> https://launchpad.net/~mysticgalaxies
> > Post to :
> mysticgalaxies@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe :
> https://launchpad.net/~mysticgalaxies
> > More help :
> https://help.launchpad.net/ListHelp
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~mysticgalaxies
> > Post to : mysticgalaxies@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~mysticgalaxies
> > More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~mysticgalaxies
> Post to : mysticgalaxies@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mysticgalaxies
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~mysticgalaxies
> Post to : mysticgalaxies@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mysticgalaxies
> More help : https://help.launchpad.net/ListHelp
Attachment:
signature.asc
Description: This is a digitally signed message part
Follow ups
References
