[Bf-committers] Python security - proposal

[Campbell Barton]

Hi Ton, 2.68 release targets look good, reply inline to other issues.

On Sun, Jun 9, 2013 at 11:02 PM, Ton Roosendaal <ton at blender.org> wrote:
> Hi all,
>
> Back to practical solutions we can work on for the next release!
> Here's a proposal I think has a wide consensus:
>
> 1) "Trusted source" for autorun scripts gets default disabled.
>
> 2) On loading a .blend with autorun script, we notify a user of that. How that UI will work exactly has a number of solutions we can investigate further. I suggest Campbell to investigate it and test some ideas and propose that here.

Sounds fine, this can be implemented in a way which communicates well
to users what happens so they can enable if they want.

> The above should be a real 2.68 target.
> Further actions we can take:
>
> 3) Implement a friendly (easy to use) way for marking/defining .blend files to be always be trusted. Also here a number of solutions are possible, like preset directories for where such files are located, or a way to sign personally saved files. Or both.
>
> I propose Campbell to investigate that further too with some people and come with a final proposal for it.

Yep, this can work too even if its not strong security it can prevent
simple attacks and make it so users dont have to deal with this for
their own projects - worth looking into.

> 4) Cleanup Blender file writing code itself as well. Like stop using /tmp for files, and enforce relative paths for (automatic) output file writing.

Sure, why not - though IMHO this is much less of a problem then py scripts.

> 5) Figure out if there's any way to detect malicious scripts...

Doubt this is possible, Python is too flexible - any detection would
be so weak to the point of being useless and give users false sense of
security.

> 6) Kick Python.org and/or support the PyPy project to get 3.x Python secured somehow.

Seeing as CPython removed their rpython module in 2.x (rather then
fixing it) and don't seem interested to include the work from the
pysandbox project, changes there seem very unlikely.

Long term PyPy is interesting, though they are still on 2.x and don't
have an embeddable C API yet,
luckily our PyC-API code is small enough that such a change isn't
unreasonable however theres are a lot more things to consider then
security with moving away from CPython.

>
> -Ton-

-- 
- Campbell