[Bf-committers] Python sandbox

[Leif Andersen]

>
> I cannot speak for the community, but my thoughts are that a "web of
> trust" misses the point. Trust systems work so long as one assumes that
> the participants are going to be a somewhat insular community. This
> works well for code, emails, and the like but artists? We're doing
>  incredibly our

 best to shield them from the technicalities on the one hand, but
> requiring them to be part of a trust network just to share files?
>

True, while I don't completely agree with the exact method Jonathon is
proposing, I still think the idea of a plugin center of sorts is a good
idea.  It seams like blender prides itself on having an incredibly small
system requirements, and download size for what it does (after all, other 3d
modeling programs takes up hundreds of MB, if not several GB of data, and it
also runs on relatively little ram (for small enough projects anyway)).  If
all of the main plugins were stored in the blender file, with blender 2.5+
allowing for very modular programing, that could get unneeded large.  On the
other hand, if the plugins are stored in a location buried deep within the
blender website/wiki/other blender community page, the user would have to
open their browser, go to that page, find the script they wanted, download
it, either put it in a plugins directory, or run a script to automatically
put it in the directory (both of which are going to be incredibly insecure,
no matter how much you sandbox python (well, unless you limited it to only
allow for a few functions that don't use indirection in any way shape or
form)), or the user would open up blender, click on an add plugin button, a
security warning would pop up, the user would then locate the file on his
hard drive, and the plugin would get added.  You could also potentially have
multiple levels of access, for example, a plugin that only allows for a
customized window wouldn't need access to the hard drive, only to a few
'button and menu objects', although, passing in the context could provide
major security flaws.

On the other hand, there could be a button in blender, that opens up a
dialog, which contains a software center, containing all of the pseudo
social aspects that plugin managers (such as the one in the wordpress
software), has.  Also, you could potentially either 'crowd source' (I hate
that phrase, if anyone has anything better, please tell me) the plugins (the
best way would likely to be to only allow for apps who's source code is
viewable, and/or to have a digg like review system), or, the default could
only be to show plugins that the blender foundation has personally verified
(which I think isn't necessarily the best way, but it would work for a few
plugins).  The user then clicks on the icon, sees a security warning, with a
link showing how the plugin center approves software, and then they can
download it.  Alternatively, if the user did find a plugin that they liked
on an external website, they could add it (either by a seperit button
outside of the center, or by an 'add from external link' button, this would
of course, pop up with a more fervent security warning.

~Leif Andersen

----------
So Much to Learn, Such Little Time
http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/


On Wed, Mar 17, 2010 at 19:45, Brecht Van Lommel <brecht at blender.org> wrote:

> Hi,
>
> On Thu, Mar 18, 2010 at 1:51 AM, Benjamin Tolputt
> <btolputt at internode.on.net> wrote:
> >> To sum up my opinion, sandboxing is very hard and not something we can
> >> solve once, it requires continuous attention, so let's not even try
> >> it. Instead, the install addon operator should warn about security
> >> problems, and loading a .blend file with scripts should become easier
> >> for users.
> >>
> >
> > Actually, sand-boxing scripts is quite easy provided you use a platform
> > that supports it. Python currently does not support this so the task
> > seems insurmountable; but only so long as you look through the Python
> > lens. It is quite simple to sandbox applications using Lua - simply
> > don't give them access to the unsecure functionality. If you don't want
> > the user reading/writing files not explicitly handed to them? Then don't
> > give them access to the "io" library (by excluding it from the VM's
> > initialisation). Don't want to give the person access to the operating
> > system, don't add the "os" module to those accessible by the VM. And so
> on.
>
> I don't think making the Blender API safe is easy. Some examples of
> things that could be exploited:
> * .blend/image/sound save operators
> * render animation operator
> * physics systems point caches writing to disk
> * open file browser + run file delete operator
> * binding keymap or buttons to an operator
> * compositing file output node
> * register operator to override .obj exporter
>
> And then there are of course the more complicated ones, memory
> corruption, buffer overruns, etc now become security issues. I bet you
> can find dozens of indirect an non-obvious ways to do damage. Now, you
> can try to figure out all those cases and add checks for them, but
> doing this well is really hard. Security issues in web browsers don't
> happen because they forgot to disable access to the IO module. And as
> new features are added to Blender this does require continuous
> attention.
>
> Brecht.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>