[OLPC Security] [sugar] secure /tmp and /var/tmp

Ivan Krstić krstic at solarsail.hcs.harvard.edu
Thu Nov 8 07:11:52 EST 2007


On Nov 7, 2007, at 9:09 PM, Albert Cahalan wrote:
> Using standard directories is not scribbling all over
> the filesystem!
> This anti-compatibility attitude needs to stop. It's really
> hurting OLPC, needlessly making the goals harder to
> achieve. Breaking compatibility is something to be done
> as a last resort, when no alterative will work.

For better or for worse, compatibility has been broken, and on a  
level as fundamental as file access. If an application can't even  
access the user's files without being aware of the datastore, what  
good is it to pretend that providing small bits of backwards  
compatibility will make things substantially easier?

For us, $SAR/tmp lives in RAM and is severely limited (maybe to as  
little as 1MB per application). $SAR/instance is used for transient  
per-instance disk-backed storage. Since it's a given that work needs  
to be done to port applications to Sugar, it's a _good_ thing that a  
programmer is also confronted with the decision as to which of these  
two temporary directories to use. Enabling a wrapper for /tmp would  
have us make that decision for them, and as fellow Python programmers  
know: explicit is better than implicit, and in the face of ambiguity,  
refuse the temptation to guess.

> The long-term goal should be to support solid sandboxing
> of true all-over-the-filesystem software installs. This may
> need a unionfs filesystem so that files can be put everywhere
> without the dummy files needed for file-on-file bind mounts.
> Imagine if you could install any RPM, knowing that it had
> no way to corrupt your OS.

That goal is not something I'm spending much time thinking about. The  
level of protection provided by Bitfrost is not something you can do  
without serious compatibility breaks with how things are done at  
present.

--
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org


More information about the Security mailing list