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

[Albert Cahalan]

On 11/7/07, Michael Stone <michael at laptop.org> wrote:
> On Wed, Nov 07, 2007 at 12:06:21PM -0500, Albert Cahalan wrote:

>> Next, bind-mount something appropriate onto /tmp and /var/tmp.
>
> I talked about this with Ivan who requested, at the time, that we
> continue using the $SAR directories instead of the FHS ones.
>
> The basic idea was that we actually _do not_ want activities scribbling
> all over the filesystem. Period. Certainly we could use the standard
> paths, as you suggest. However, it was an intentional design decision to
> break compatibility with the FHS.

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.

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.

> > ...where "12345" is the UID, perhaps allocated as the PID of
> > the current (root) process plus 10000.
>
> I wish it were as easy as just setting the pid to something high, but
> unforunately, Sugar gets cranky when /etc/passwd and /etc/group don't
> contain accurate information about the pid and and primary gid of the
> program that's running.

Oh. Well, you don't have to work around that bug
if you fix it. :-)

>> That's one less portability problem. $(SUGAR_ACTIVITY_ROOT)/tmp
>> can just go away.
>
> Do you have some examples of programs which don't listen to $TMPDIR and
> which don't take explicit paths to non-volatile storage? If so, would it
> not be more appropriate to make these programs even more portable by
> removing assumptions they're making about the environment in which
> they're running?

$TMPDIR doesn't cover /var/tmp, and vi uses /var/tmp, so I
guess that would be one.

Never minding if it would be a good idea to modify any such
programs, needlessly making them fail is a very bad idea.