linux-kernel - RE: [PATCH v3 3/5] LSM: Security module checking for side-channel dangers

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] [day] [month] [year] [list]

Message-ID: <99FC4B6EFCEFD44486C35F4C281DC673214407ED@ORSMSX107.amr.corp.intel.com>
Date:   Wed, 22 Aug 2018 17:48:02 +0000
From:   "Schaufler, Casey" <casey.schaufler@...el.com>
To:     Jann Horn <jannh@...gle.com>
CC:     Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        kernel list <linux-kernel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        "selinux@...ho.nsa.gov" <selinux@...ho.nsa.gov>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Dock, Deneen T" <deneen.t.dock@...el.com>,
        "kristen@...ux.intel.com" <kristen@...ux.intel.com>,
        Arjan van de Ven <arjan@...ux.intel.com>
Subject: RE: [PATCH v3 3/5] LSM: Security module checking for side-channel
 dangers

> -----Original Message-----
> From: Jann Horn [mailto:jannh@...gle.com]
> Sent: Wednesday, August 22, 2018 10:04 AM
> To: Schaufler, Casey <casey.schaufler@...el.com>
> Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>; kernel list
> <linux-kernel@...r.kernel.org>; linux-security-module <linux-security-
> module@...r.kernel.org>; selinux@...ho.nsa.gov; Hansen, Dave
> <dave.hansen@...el.com>; Dock, Deneen T <deneen.t.dock@...el.com>;
> kristen@...ux.intel.com; Arjan van de Ven <arjan@...ux.intel.com>
> Subject: Re: [PATCH v3 3/5] LSM: Security module checking for side-channel
> dangers
> 
> [SNIP]

> > Yes, but in a different namespace. Hence the namespace check.
> >
> > What I hear you saying is that you don't want the capability check
> > to be independent of the namespace check.
> 
> The capability check doesn't always require a namespace match, and I
> don't care about non-user namespaces here, but I would prefer it if
> A->B with A having some capabilities required A's user namespace to be
> ancestor-or-self of B's user namespace. But alternatively:

Looking at ancestor relations starts to get us pretty close to the
point where the cost of checking will overwhelm the savings. This
is something we have to be very careful of.

> > This conflicts with the
> > strong desire expressed to me when I started this that the configuration
> > should be flexible. I can beef up the description of the various options.
> > Would that address the issue?
> 
> It seems to me that it would make sense to express this as something
> like a Kconfig dependency.

I thought about that. It could be the best choice. I will investigate
further.

> But I guess if you document that the
> combination of CONFIG_USER_NS=y,
> CONFIG_SECURITY_SIDECHANNEL_NAMESPACES=n and
> SECURITY_SIDECHANNEL_CAPABILITIES=y is nonsensical, that works too. I
> just don't see why you'd want to provide such a footgun?

Point.

> Configurability is nice, but if we know that one of the possible
> configurations doesn't make sense, it seems like a good idea to just
> not allow the system to be configured that way.

Another point.

> You say that you were asked to make the configuration flexible. Did
> whoever told you that actually want the ability to compare raw
> capability sets on a system with CONFIG_USER_NS=y, and understand what
> semantics that has (and doesn't have)? Or was their intent more along
> the lines of "we want to flush if the new task has higher privileges,
> capability-wise, than the old task; but we don't explicitly care about
> namespaces"?

Without going into too much detail, it's a matter of people who
understand chips and performance better than they understand
security or the user experience.