-----Original Message-----
From: James Morris [mailto:jmorris at namei.org]
Sent: Friday, September 28, 2018 9:33 AM
To: Jann Horn <jannh@google.com>
Cc: Schaufler, Casey <redacted>; Casey Schaufler
[off-list ref]; kristen at linux.intel.com; Kernel Hardening
[off-list ref]; Dock, Deneen T
[off-list ref]; kernel list [off-list ref];
Hansen, Dave [off-list ref]; linux-security-module <linux-security-
module at vger.kernel.org>; selinux at tycho.nsa.gov; Arjan van de Ven
[off-list ref]
Subject: Re: [PATCH v5 5/5] sidechannel: Linux Security Module for sidechannel

On Fri, 28 Sep 2018, Jann Horn wrote:

quoted

quoted

so with this hard-coded logic, you are saying this case is
'safe' in a sidechannel context.

Which hints at the deeper issue that containers are a userland
abstraction.  Protection of containers needs to be defined by userland
policy.

Or just compare mount namespaces additionally/instead. I think that
containers will always use those, because AFAIK nobody uses chroot()
for containers, given that the kernel makes absolutely no security
guarantees about chroot().

We can't define this in the kernel. It has no concept of containers.

People utilize some combination of namespaces and cgroups and call them
containers,

There is an amazing variety of things called containers out there.
I cite them as a use case, not a requirement.

but we can't make assumptions from the kernel on what any of
this means from a security point of view, and hard-code kernel policy
based on those assumptions.

We can assume that namespaces are being used as a separation mechanism.
That makes processes in different namespaces potentially vulnerable to
side-channel attacks. That's true regardless of whether or not someone is
using namespaces to implement containers. 

This is violating the principal of separating mechanism and policy, and
also imposing semantics across the kernel/user boundary. The latter
creates an ABI which we can then never break.

The effects of the sidechannel security module are not API visible.
The potential impact is on performance. This implementation of
PTRACE_MODE_SCHED does not change what happens, but may affect
when it happens. It is intended to aid in optimizing the use of expensive
anti-side-channel countermeasures.