Rick Yorgason wrote:
> The moral of the story is that the danger of attacks is directly
> proportional to the popularity of your product, so every time you work
> to make Blender more popular, you're also raising the danger of attacks.
> Clearly, something has to be done sooner or later, unless y
I've been following this discussion for a while. Incidentally, I just
read a little blurb from Herb Sutter's blog regarding security:
http://herbsutter.com/2010/03/22/links-i-enjoyed-reading-this-week-2/
The moral of the story is that the danger of attacks is directly
proportional to the popular
@Wahoony, detecting bad calls wouldn't work well, you could easily
construct commands and execute them without the parser knowing. Even
stupid stuff like making each character an item in a list, joining it,
and running would work.
@Chris, since python is embedded in blender this would mean sandbox
That would be about as successful as an Australian Internet Filter
Probably the easiest way to sandbox the python scripts is to sandbox the
python executable within the OS itself. That is, set up a dummy user within
the OS with no login rights, etc and do a run as.
Then all that you have to do to
I had a thought regarding this sandbox/security business.
Wouldn't it be possible to pre-parse the python script in question and
flag potentially harmful functions and then perhaps mark them as
potentially malicious (kind of like a Bayesian spam filter), there will
be some leg work to begin wit
That's assuming that:
A. The user knows he has malicious software on his computer.
B. Knows where it came from, and what not to install to get it to happen
again.
C. If he has incorporate the stuff into blender itself (which is IMO too
easy to do in the current version of blender, or at least
> , there needs to be a way of recuperating
>
> ~Leif Andersen
Load your most recent backup files, assuming your entire project has been
erased.
Mike Belanger ( Mikahl )
www.watchmike.ca
>
>
> --
> So Much to Learn, Such Little Time
> http://leifandersen.net/2010/02/03/so-much-to-le
Joe;
Yes, but on the off chance that the user does add a malicious .blend file?
As was said earlier in this thread, there needs to be a way of recuperating
from it, if at all possible. Putting a pop up only solves half of the
problem. (Then again, I think providing a good way to recuperate will
Is any of this a problem in practice? What do other applications do?
Seems to me we might be making this too complicated. Just have a
"warning: this .blend has scripts, which can be dangerous if you don't
trust the author; enable scripts?" popup on loading .blends.
For something as complex as a d
Hi Leif, probably repeating myself here but I don't understand the
rationale for some of your suggestions.
- Secure+Updated script installation doesn't help much since blend
files themselves can include auto-executing drivers.
- Separate python doesn't help with security, unless its separated in
su
As sad as it is, it seams like your axiom Jonathan, has been true.
Although, that is based only on empirical evidence, not an actual rigorous
proof. (i.e., I would die happy if I ever found a way to make a computer be
secure, and work seamlessly). Some examples of this are the previous emails
in
To me its not a question of how secure your pipeline is, but how quickly you
can 'bounce back' after a system failure, maliciously-motived or otherwise.
Yeah, you should have a firewall, passwords, admin rights etc. But really,
the best insurance policy for studio assets is automated-backup.
If an
On 18/03/2010, at 15:09 , §ĥřïñïďĥï Ŗäö wrote:
> Hi,
> This is my very first mail to this list . I am not a developer but I
> thought
> i will put my 2 cents here since I felt that this discussion is a
> waste of
> time for many reasons .
> 1: +100 for Brecth and his opinion (He is perfectly
Hi,
This is my very first mail to this list . I am not a developer but I thought
i will put my 2 cents here since I felt that this discussion is a waste of
time for many reasons .
1: +100 for Brecth and his opinion (He is perfectly right !!)
2: sanboxing blender will make it unusable in large pipe
hi.
First off, Leif, thanks for volunteering to study this set of ideas!
And thanks to all for the excellent comments and opinions expressed so
far!
I would like to forward what I've been calling my axiom of usability
in computer security for the last 10 years or so:
"Computer security is
Leif Andersen wrote:
> 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.
I have no issues with this at all. The plugins that come with Blender
are trusted by default and a central location to fin
>
> 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
Hi,
On Thu, Mar 18, 2010 at 1:51 AM, Benjamin Tolputt
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 load
Brecht Van Lommel wrote:
> First is that there is a difference between python scripts, one
> category is scripts to extend blender like exporters. These
> fundamentally can't run inside a sandbox since they need to access
> files.
>
This is, indeed, not new and I know it has been mentioned mul
Leif Andersen wrote:
> I really like Jonathan's idea. Perhaps some sort of distributes/crowd
> sourced 'plugin center' for blender, that relies on a web of trust. I think
> that is a great idea, and unless the community thinks it's a horrible idea,
> I will submit a GSoC proposal on it.
>
I c
Hi,
I don't think I'm bringing up anything new here but would like to
point out some things.
First is that there is a difference between python scripts, one
category is scripts to extend blender like exporters. These
fundamentally can't run inside a sandbox since they need to access
files. Some c
I really like Jonathan's idea. Perhaps some sort of distributes/crowd
sourced 'plugin center' for blender, that relies on a web of trust. I think
that is a great idea, and unless the community thinks it's a horrible idea,
I will submit a GSoC proposal on it.
~Leif Andersen
--
So Much to
hi.
I feel that I must raise the issue of *trust* again. It is extremely
relevant to this issue, and many others now facing many FOSS
communities, particularly blender.
The problem is running *untrusted* code. The trust in this case,
really comes down to trusting the script's author.
Perh
We can ignore script installation issues or anything related to
blenders API's...
if you can run a line of python (such as a pydriver) among other evil
things you can remove the users home dir.
eg, valid one line driver which wont raise and error.
0.0 if __import__("shutil").rmtree(__import__("os
Hi,
I'm new to the list, but wanted to add my thoughts. I've used the
blender 2.49 py api a lot in my work as a Flash developer specialized
at 3D, mostly writing custom exporters, and am currently working on
the 2.50 api and scripts.
I agree with Campbell that there's really no problem in a
hehe, use lua :D, I shouldnt have suggested this at lunch today!
one day I'm told the API needs to be stabilized ASAP, the next,
suggestion to switch languages.
I cant take this seriously!
LetterRip, both blender2.5 and Maya include their own python, so it
doesn't matter if the user has python ins
Ton,
on a farm blender would only have access to the folder that the admin has setup.
Any computer that has python installed has the exact same security risks.
These days, pretty much every computer has python preinstalled,
especially one used for animation.
Every animation tool has the same is
Hi,
I am not talking about "make everything in Python run sandboxed". The
target can be narrowed down to a simpler task:
1) support animation scripts (drivers, constraints, fcurve mods)
2) interface scripts
3) basic import and export
If '3' or even '2' is not possible, we then can try '1' eve
the problem is not so that someone would tamper with the python installation.
Its mainly that you can include malicious python code inside a blend
file in a driver or registered script.
On Wed, Mar 17, 2010 at 2:16 PM, Leif Andersen
wrote:
> I was thinking of submitting a GSoC proposal about this
I was thinking of submitting a GSoC proposal about this, although just a sub
section of it, for as you point out, it is a rather large project.
It would make sense to me, to include python, as a separate module when the
user downloads blender. It then checks to see if python has been installed
on
--- On Wed, 3/17/10, Campbell Barton wrote:
> I'm not interested in this for a few reasons...
>
> * Its a lot of work, even python guys have trouble to do
> this well and
> there are way more python developers then blenders.
For this exact reason, I think it's totally outside the scope of GSO
On Wed, Mar 17, 2010 at 9:50 AM, Ton Roosendaal wrote:
> Hi all,
>
> In past discussions I had the impression that Blender's Python cannot
> be simply sandboxed because python.org doesn't cooperate with it.
> Second reason was that Blender apparently is one of the few apps
> embedding Python on su
Ton Roosendaal wrote:
> Perhaps a Google SoC project to secure Blender's Python could help here.
>
For people considering this, be aware that securing embedded Python
(which is what this amounts to) is a *very* large task. There is a
reason a "secure Python" isn't out & about, and it is not onl
Hi all,
In past discussions I had the impression that Blender's Python cannot
be simply sandboxed because python.org doesn't cooperate with it.
Second reason was that Blender apparently is one of the few apps
embedding Python on such a level.
Philipp Guehring sent me these links and a sugge
34 matches
Mail list logo
