Security

Using Boodler means downloading Python code and executing it. This means security headaches. Any given soundscape could contain code to delete your files as easily as it could play bingley noises.

(There is no sandbox facility for current Python. There used to be, but the language grew in power to the point where it could climb out of the sandbox.)

My current theory of security goes like this:

  • Inspect soundscapes as they're uploaded to the web site. This will be easy at first, and hard when Boodler takes off and conquers the world. I can do a certain amount of automated inspection (grepping for dangerous constructs) but obfuscated source code can always run rings around this.

  • Have a complaints system, where users can report a given soundscape as malicious.

  • Run the sound-generation part of Boodler (see GUI) in a restricted Python binary. I have divided up the functionality so that one layer needs to use the network and write files, and another layer needs to execute soundscape code, and the two can be in different processes. It should be possible to build a version of Python with the file-writing and network modules compiled out. (I have not researched this, however.)

    • A malicious soundscape could work around this restriction by including native-compiled code in the soundscape package. But that's pretty easy to detect at upload time.
Security - last changed 2007-06-04 15:37 by Andrew Plotkin (zarf)