linux-kernel - Re: [Patch v6 14/16] x86/speculation: Use STIBP to restrict speculation on non-dumpable task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 21 Nov 2018 12:07:46 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, thomas.lendacky@....com,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        "Mallick, Asit K" <asit.k.mallick@...el.com>,
        "Van De Ven, Arjan" <arjan@...ux.intel.com>, jcm@...hat.com,
        longman9394@...il.com, Greg KH <gregkh@...uxfoundation.org>,
        david.c.stewart@...el.com,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        stable@...r.kernel.org
Subject: Re: [Patch v6 14/16] x86/speculation: Use STIBP to restrict
 speculation on non-dumpable task

On 11/20/18 5:27 PM, Linus Torvalds wrote:
> Also, "dumpable" in general is pretty oddly defined to be used for this.
> 
> The same (privileged) process can be dumpable or not depending on how
> it was started (ie if it was started by a regular user and became
> trusted through suid, it's not dumpable, but if it was started from a
> root process it remains dumpable.
> 
> So I'm just not convinced "dumpability" is meaningful for STIBP.

I think we're hoping that "dumpability" is at least correlated with
sensitive processes.  As you've pointed out, it's not a strict
relationship, but there's still some meaning.

Let's not forget about things like gpg that do PR_SET_DUMPABLE
completely independently of the actions that trigger the
/proc/sys/fs/suid_dumpable behavior.  Those will be non-dumpable
regardless of how they were started.

In addition, things that are started via suid surely *do* have more
attack surface than something started by root.  We've been positing that
these attacks get easier when the attacker and victim have a
relationship, either via RPC, or the network, or *something*.  suid
basically *guarantees* there's a relationship between the privileged
thing and _something_ untrusted.

Repurposing dumpable is really screwy and surely imprecise, but it
really is the closest thing that we have without the new ABI.