libseed-list Fwd: Security overview

[Robert Carr <racarr gnome org>]

---------- Forwarded message ----------
From: Robert Carr <racarrg gmail com>
Date: Tue, May 17, 2011 at 6:12 PM
Subject: Re: libseed-list Security overview
To: Tim Horton <tim hortont com>
Cc: Michael Terry <michael terry canonical com>, libseed-list gnome org


On Tue, May 17, 2011 at 4:30 PM, Tim Horton <tim hortont com> wrote:
> On 2011.05.17, at 15:48, Michael Terry wrote:
>
>> Hello, gentle Seed developers!
>>
>> I do work on the Ubuntu desktop team and am looking into getting seed into the main archive so that it can ship with Ubuntu 11.10 as part of GNOME 3 [1].
>>
>> Part of that process is a security review and this comment was made by Kees Cook, a member of the security team:
>>
>> """
>> Yikes, javascript hooked to the desktop. :) There's nothing immediately wrong with the code, but I have to wonder about how security boundaries are going to be enforced, if JS from the browser ever touches JS for the desktop. I would prefer to see documentation similar to the "same origin" policies in browsers for how JS will be used in the Desktop before this package goes into main.
>> """
>>
>> Maybe my Google-fu is weak, but I couldn't find discussions of seed security or XSS issues.  Though apparently it has some support for sandboxing?
>>
>> Also in general with seed, who is responsible for enforcing or activating security protections?  Like, do Gedit plugins have to specifically ask seed to use sandboxing or whatever?  (i.e. do we just have to worry about seed screwing up, or do we also have to look at all users of seed?)
>
> I'm a bit confused - Seed is just bindings: no different than, for example, PyGObject, or gjs, or any of these [2] (especially gjs!). In practice, it's no different than any other scripting language on your system with GObject bindings. Seed has no interaction at all with "browser-side" JavaScript.
>
> Security implications for Seed scripts are - as far as I'm aware - exactly the same as for Python scripts or the like (none of which have anything like Web-JS's "same origin" policies).
>
> Maybe Robb can shed some light.
>
> [2] http://live.gnome.org/GObjectIntrospection/Users
>
>> Thanks!
>>
>> [1] https://bugs.launchpad.net/ubuntu/+source/seed/+bug/782972
>>
>> -mt
>> _______________________________________________


Hi!

Glad to see that there is still interest in Seed...sometimes I felt
like no one had any interest (part of the reason nothing major has
happened with it lately, at least from me).

Like Tim says, the security implications are essentially the same as a
python script. Seed uses only the JavaScriptCore portion of
webkit...you could draw the following analogy:

seed:JavaScriptScore::pygobject:libpython

Certainly using the libseed C library, applications can expose
GObject's to browser side javascript (and actually this may be soon in
WebKit itself, as discussed on the list recently). This has nothing to
do with the plugin situation though, and I would hope anyone writing
such an application would think very carefully about the security...

As for sandboxed plugins...well I'm not really sure how large the use
case for this is in most cases, most python plugin systems aren't
sandboxed right? Hypothetically Seed does contain some code where you
can limit the modules usable in a context. An extension library could
allow per method/type granularity. I can't think of any reason off the
top of my head why this system is not secure (and sandboxing
JavaScript is a much simpler problem than say Python...), but I
haven't exhaustively shown it, because I don't think there's any use
at the moment.