[sugar] secure /tmp and /var/tmp

[Stephen John Smoogen]

On Nov 7, 2007 7:09 PM, Albert Cahalan <acahalan at gmail.com> wrote:
> 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.
>

A couple of questions from someone who is trying to catchup on what he
might be able to do

1) How much indirection can the CPU handle via various layers (say
unionfs ontop of unionfs etc) without bogging down the system?
2) How much can the flash drive handle per throughput AND lifetime limits?
3) How much can the memory system handle? since... I don't think we
want to hit swap.

If all these are generally known and been discussed already.. sorry.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"