Re: Are plasmoids expected to be good citizens

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: Are plasmoids expected to be good citizens
by Sebastian Sauer on Tuesday 25/Mar/2008, @07:54

> To give an example, at a SAFE level of 2 you are prevented from doing File.chmod, but you're free to do Kernel.system("chmod +x blah").

y, cause T2 is about "Ruby prohibits the loading of program files from globally writable locations." and has nothing to do with chmod+userfiles. Use at least T3 or even better T4.

but I agree that those "safe levels" are not really what someone may understand under sandbox too since it would still be needed to provide secure wrappers for things like readfile, chmod, etc. if they should be limited to defined locations :-( Same was the case with Zope2 RestrictedPython and since I still believe it's better to provide no security then false security, I just did removed it in KDE4 - the Zope3 solution really looks very good but is to huge to be adopted :-(

Guess my initial point of "none of them is _the_ solution if it comes to security" is still valid even if I wish that wouldn't be the case :-(

Related Links

·   Articles on Developer
·   Also by Sebastian Sauer
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: Are plasmoids expected to be good citizens
by Sebastian Sauer on Tuesday 25/Mar/2008, @07:57

and before I forget it, there is the nice document "Sandboxing of Dynamic Code" around which does provide some good (but in the case of Python outdated) details related to that topic; http://rune.hammersland.net/tekst/sandbox.pdf

[ Reply To This | View ]

Re: Are plasmoids expected to be good citizens
by Richard Moore on Tuesday 25/Mar/2008, @07:59

Another thing with the ruby safe levels is that they seem very oriented to web apps operating on untrusted data rather than apps embedding the interpreter operating on untrusted code. eg. only at a safe level of 4 is the script prevented from terminating your application.

> Guess my initial point of "none of them is _the_ solution if it comes to
> security" is still valid even if I wish that wouldn't be the case :-(

I think that's a pretty fair assessment. It's not the answer I'd like either though. :-(

The java security manager approach is the only real way I've seen to get truly fine grained control, and that is extremely complex and requires hooks in all your libraries. Even then it has been bypassed on a number of occaisions (possibly because it is too complex to test effectively).

[ Reply To This | View ]

Re: Are plasmoids expected to be good citizens
by Sebastian Sauer on Tuesday 25/Mar/2008, @09:17

> eg. only at a safe level of 4 is the script prevented from terminating your application.

Does you have a source for this? I ask cause, well, we are using Ruby and I never did note such behavior. What for sure is a bit annoying and probably related is that it's needed to wrap each C-functioncall into a secure-fallback function to catch exceptions explicit. If that isn't done and if the call throws an exception, the application will crash (same with T4 btw). The reason for that design was to maximize the performance by being able to select what C-functions may throw an exception (that needs to be catched) and which one are not. Guess that's very inline with the overall design-goal of Ruby to provide the fastest scripting-environment out there on earth.

> The java security manager approach is the only real way I've seen to get truly fine grained control, and that is extremely complex and requires hooks in all your libraries.

y, true. That's really one of the best solutions I saw so far but also comes with so much downsides. Very much like something like SE-Linux which if used wrong may provide more trouble then solving any.

> Even then it has been bypassed on a number of occaisions (possibly because it is too complex to test effectively).

and judging from the 1.6 showstopper-bug I run into (known since more then 2 years btw) I wouldn't wonder if there are no automated tests for such things at all :-/

[ Reply To This | View ]

Re: Are plasmoids expected to be good citizens
by Richard Moore on Tuesday 25/Mar/2008, @10:36

> Does you have a source for this?

This is the best doc I've found on ruby safe levels (especially the table at the bottom):
http://phrogz.net/ProgrammingRuby/taint.html

[ Reply To This | View ]

Re: Are plasmoids expected to be good citizens
by Sebastian Sauer on Tuesday 25/Mar/2008, @11:17

> http://phrogz.net/ProgrammingRuby/taint.html

Thanks for that link and now I am impressed since at $SAFE>=2 it really says chmod should be prevented. Uh, I've to add. That's really new to me and its even more surprising it's written down in a book while being just not true/valid. Guess that was the last destroyed difference between books and TV :)
Re $SAFE>=4 and "Can't invoke exit, exit!, or abort." Neither exit or abort works if embedded, but exit! does and that even with SAFE==4. Hmpf, http://www.math.hokudai.ac.jp/~gotoken/ruby/man/function.html#exit_bang says unlike abort and exit the exit! function ignores any handlers. Fine :-( Anyway, added to my todo and will be fixed asap, thanks for that hint!

[ Reply To This | View ]

Re: Are plasmoids expected to be good citizens
by Richard Moore on Wednesday 26/Mar/2008, @02:10

Yes, I checked the ruby source code too and the code matches this reference.

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"We've been wondering, are Andreas Pour and Navindra Umanee the same person?" -- Charles Samuels
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.