[MODERATED] Re: [PATCH SSBv11 0/3] seccomp 1

[Kees Cook <kees@outflux.net>]

On Thu, May 03, 2018 at 04:09:32PM +0200, speck for Ingo Molnar wrote:
> * speck for Thomas Gleixner <speck@linutronix.de> wrote:
> > On Thu, 3 May 2018, speck for Andi Kleen wrote:
> > > On Wed, May 02, 2018 at 05:44:27PM -0700, speck for Kees Cook wrote:
> > > > From: Kees Cook <keescook@chromium.org>
> > > > Subject:  opt-in under seccomp
> > > > 
> > > > As seccomp use overlaps best (though not perfectly) with applications
> > > > most likely to want speculation flaw mitigations enabled, seccomp will
> > > > enable them when seccomp is enabled for a task. Also adds a line to
> > > > /proc/$pid/status for examining the mitigation state of a task.
> > > 
> > > As I wrote earlier this isn't a good idea. We went through
> > > this earlier. 
> > > 
> > > It originally seems like a good idea until you start looking at the details.
> > > 
> > > The big users of seccomp like the web browsers eventually
> > > don't want it once they use site isolation. And it would
> > > unnecessarily slow them down.
> > > 
> > > And other programs need to be maintained anyways (e.g. for 
> > > spectre variant 1 fixes) so they can as well add it explicitely.
> > > 
> > > Separate enabling makes more sense. And that is already in the patchkit.
> > 
> > You're just ignoring the fact that they are not having it today and it's
> > about providing the best out of the box protection right now.
> > 
> > Telling people: "We have this shiny new prtcl and your browser will
> > eventually use it but until then you're on your own." is just bullshit.
> > 
> > Kees certainly knows what he is talking about and being involved in chrome
> > gives him definitely more weight than your 'eventually don't want' and
> > 'have to be maintained anyways' advisories which have exactly zero
> > technical content.
> 
> The other problem with 'site isolation' is that it doesn't necessarily solve or 
> even mitigate the problem: if for example malicious Javascript is injected from an 
> ad network, supposedly safely sandboxed, but it can still anomalously read site 
> local data via leaky speculation then that's still a dangerous violation of 
> sandboxing constraints: it could read pointers to defeat ASLR, it could read local 
> keys or other data it's not supposed to read.
> 
> Once a browser specifically knows that it has fully mitigated against an attack it 
> can turn off any default mitigation early in its init sequence via the prctl, when 
> it still has full OS access and no seccomp isolation. All child tasks should 
> inherit that.

My goal is providing SOME kind of "by default" coverage that doesn't
require an admin to write new code or wait for a software vendor to provide
an update.

If it is tolerable to wait for a vendor to _enable_ the mitigation, then
it should be tolerable to wait for a vendor to _disable_ the mitigation
as well. i.e. we protect a targeted subset of processes (those using
seccomp) but provide a way to disable it later. To that end, how about
a new prctl or seccomp flag that indicates "do no enable speculation
mitigations under seccomp"? That would give any seccomp users the ability
to opt-out if they wanted to.

-Kees

-- 
Kees Cook                                            @outflux.net