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

[Jim Gettys]

I sympathize with Albert's point here: we should be no more incompatible
than we have to be...  Just because we have to break some things,
doesn't mean we have to break everything.
                              - Jim


On Thu, 2007-11-08 at 10:42 -0500, Albert Cahalan wrote:
> On 11/8/07, Ivan Krstić <krstic at solarsail.hcs.harvard.edu> wrote:
> > 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?
> 
> One failure is no excuse to purposely fail in every way.
> 
> Not every application even needs access to a user's files.
> 
> The datastore has changed and apparantly will change.
> Perhaps it can someday be less awkward to deal with.
> 
> In any case, yes, it is extra work and ugly code.
> You're affecting every porting effort; it must be easy
> to make that decision when it's somebody else's
> code base getting screwed with #ifdef everywhere.
> 
> > 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.
> 
> This is nothing new. It's been standard on SunOS for ages.
> The /tmp directory is in RAM, and /var/tmp is on disk.
> You are not so special that you need to break everything.
> AFAIK, this is even a common (normal?) setup on BSD.
> 
> BTW, if you're going to keep calling it $SAR, then you'd
> better make that the real name of the variable.
> 
> > > 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.
> 
> If you don't solve it, people will just turn Bitfrost off.
> _______________________________________________
> Security mailing list
> Security at lists.laptop.org
> http://lists.laptop.org/listinfo/security
-- 
Jim Gettys
One Laptop Per Child