Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5364332imm; Tue, 21 Aug 2018 10:26:19 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwAbxOmWNNJunfgOChoKj5x6Nw3WmznLS3UpDBEAWgm4ocPsCbUtkMLJQt/7wLzPKbQVmV7 X-Received: by 2002:a63:2d84:: with SMTP id t126-v6mr15845050pgt.128.1534872379195; Tue, 21 Aug 2018 10:26:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534872379; cv=none; d=google.com; s=arc-20160816; b=lGO6KmNevHX9GNFUNOfWCe8weppylb+BW9OW3OptMKliggvPuQjd3gXwutDhoBGZin w3KPtBPsL24YMT/HNxCGKMNtFTf/Yq2mT0DWHqIYV3quZV16BjCwmix7zGISjMG4SfSO jPwKoYx90Ibrcp//808J8NBh8hkB7lOkSaZwaEVe61VCDZ1RAYNDN3lANoq1+HPe5cFT MAiaHKT6douZd2V8UyQOwioBtY+iH2F2SktYz2Shm7/NdXKq4CI5JjUfdj2/ApaOvgfW VqcXtmbQtTdB8XPrtsKwryWK+1kkgcQE3sjquBGPjGct855PBPsDgwdT43GeFMt4Ok9v TXXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=RWGilGlT6U1QaTL6FhIRIwBE8gvGjbdmOEDu9+bJbt0=; b=sQ5uWuDzo4mN42yDwtKlPTq9DpgfgoN7mkexZ7mWfgw2KjY31FPR0qfbi7j0BVIZeI cT4biC+VVINpIlh4R0j/KXJ6XzOEcTzZtJsdg083Z8f9hxG0OBKeX8bbfxt1GGrAcWWR 4ohY3g96bCs3lYdqH7o6jN63wLE4wuVYLP6GoxrDgvJx7iYGO7zn4ZEEHWBMMROUKinb dDizhf14D+oaq5W8aMI1S/pRIek/mSPc8j2k8/pZwZj1fURcjdYgguxeLxFq2/Fg9xnc 2OC06OImQDSRlDpxdvoLKvw00k/obShAHcudTfBSJNk5xZ0JZC0SpThMxaO04sE73w+S Vp+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZQxaJgJ9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k3-v6si13027035plt.328.2018.08.21.10.26.03; Tue, 21 Aug 2018 10:26:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZQxaJgJ9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727059AbeHUUp2 (ORCPT + 99 others); Tue, 21 Aug 2018 16:45:28 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:37107 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726810AbeHUUp2 (ORCPT ); Tue, 21 Aug 2018 16:45:28 -0400 Received: by mail-oi0-f68.google.com with SMTP id j205-v6so33408552oib.4 for ; Tue, 21 Aug 2018 10:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RWGilGlT6U1QaTL6FhIRIwBE8gvGjbdmOEDu9+bJbt0=; b=ZQxaJgJ9ZJYsBSjmKjlBvKZBuPMxDE72XJKm2T7rhuFRZwQqhXuEq2gJy7mrIspxHp HmNF6Y8OK0LcbAidVlm1ahYj1S83FNFUwWLk5fnH2fGx33EgI1lMhguBa2aSLXtg287d hIe/fl0d1HJUFXVq4Y6iUYSs4nTomUkutlZbvyxXwma0Cw3fLG/FjKlURZBlSHCQKHHx HJr93yVxL/Of/fl8o4wvoWLjtS969rWpneC3QkEPsp5CT17jJ4E9vsXCYfZORm6BmcmF yJpN/AasAWtRyWQ37t6Kh4GbT5fbY6rpuZelW4MZDQS9oCgYC+qYuKZS4z02+bBwTHi6 THFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RWGilGlT6U1QaTL6FhIRIwBE8gvGjbdmOEDu9+bJbt0=; b=a2r2YjXHsRFnFd2a/cJ9DLuJiKXMPIxDJZsJ2pkCj1gShQxYy0d4hc4965zG7Nki0u EL069RFjYP9yotO+6oeVk4E/WHYt5bRg3H0CO8AkAmlWFEOJqWhYO7fCWj7I7mP+azT/ EzbOLed2RyFOMs+bpqg8+ozfKaoI3S0bYRMI6lrO0Iw1CQUlQPgBqgdNgh2PpQ1Hu5KL R/Hp9eESZCC+D4AFw/yr9t0klFGXsCQkSoojTVaxHYVRREZO0Ickqq3n79oGws4C9g7H l9xkCITO0Hs+bzLj8pofCguA8XcVmErnk8yxmftrI7PtLtyqhmmzTjiz9yylXv2rnmKn wwPA== X-Gm-Message-State: APzg51DcJ/hMjA5sb4eeDPX1C8yX+w5oBZqTXCaFTjEZmyE1f6XFXfQr 9Z3Ocr8ETO/uzhXygmVXyuf/qRyvbPstQxHW84U9iQ== X-Received: by 2002:aca:dc55:: with SMTP id t82-v6mr214854oig.159.1534872264879; Tue, 21 Aug 2018 10:24:24 -0700 (PDT) MIME-Version: 1.0 References: <20180821000444.7004-1-casey.schaufler@intel.com> <20180821000444.7004-4-casey.schaufler@intel.com> In-Reply-To: <20180821000444.7004-4-casey.schaufler@intel.com> From: Jann Horn Date: Tue, 21 Aug 2018 19:23:58 +0200 Message-ID: Subject: Re: [PATCH v3 3/5] LSM: Security module checking for side-channel dangers To: Casey Schaufler Cc: Kernel Hardening , kernel list , linux-security-module , selinux@tycho.nsa.gov, Dave Hansen , deneen.t.dock@intel.com, kristen@linux.intel.com, Arjan van de Ven Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 21, 2018 at 2:05 AM Casey Schaufler wrote: > > The sidechannel LSM checks for cases where a side-channel > attack may be dangerous based on security attributes of tasks. > This includes: > Effective UID of the tasks is different > Capablity sets are different > Tasks are in different namespaces > An option is also provided to assert that task are never > to be considered safe. This is high paranoia, and expensive > as well. > > Signed-off-by: Casey Schaufler > --- [...] > diff --git a/security/sidechannel/Kconfig b/security/sidechannel/Kconfig > new file mode 100644 > index 000000000000..af9396534128 > --- /dev/null > +++ b/security/sidechannel/Kconfig [...] > +config SECURITY_SIDECHANNEL_CAPABILITIES > + bool "Sidechannel check on capability sets" > + depends on SECURITY_SIDECHANNEL > + default n > + help > + Assume that tasks with different sets of privilege may be > + subject to side-channel attacks. Potential interactions > + where the attacker lacks capabilities the attacked has > + are blocked. > + > + If you are unsure how to answer this question, answer N. > + > +config SECURITY_SIDECHANNEL_NAMESPACES > + bool "Sidechannel check on namespaces" > + depends on SECURITY_SIDECHANNEL > + depends on NAMESPACES > + default n > + help > + Assume that tasks in different namespaces may be > + subject to side-channel attacks. User, PID and cgroup > + namespaces are checked. > + > + If you are unsure how to answer this question, answer N. [...] > diff --git a/security/sidechannel/sidechannel.c b/security/sidechannel/sidechannel.c > new file mode 100644 > index 000000000000..4da7d6dafdc5 > --- /dev/null > +++ b/security/sidechannel/sidechannel.c [...] > +/* > + * safe_by_capability - Are task and current sidechannel safe? > + * @p: task to check on > + * > + * Returns 0 if the tasks are sidechannel safe, -EACCES otherwise. > + */ > +#ifdef CONFIG_SECURITY_SIDECHANNEL_CAPABILITIES > +static int safe_by_capability(struct task_struct *p) > +{ > + const struct cred *ccred = current_real_cred(); > + const struct cred *pcred = rcu_dereference_protected(p->real_cred, 1); > + > + /* > + * Capabilities checks. Considered safe if: > + * current has all the capabilities p does > + */ > + if (ccred != pcred && > + !cap_issubset(pcred->cap_effective, ccred->cap_effective)) > + return -EACCES; > + return 0; > +} On its own (without safe_by_namespace()), this check makes no sense, I think. You're performing a test on the namespaced capability sets without looking at which user namespaces they are relative to. Maybe either introduce a configuration dependency or add an extra namespace check here? > +static int safe_by_namespace(struct task_struct *p) > +{ > + struct cgroup_namespace *ccgn = NULL; > + struct cgroup_namespace *pcgn = NULL; > + const struct cred *ccred; > + const struct cred *pcred; > + > + /* > + * Namespace checks. Considered safe if: > + * cgroup namespace is the same > + * User namespace is the same > + * PID namespace is the same > + */ > + if (current->nsproxy) > + ccgn = current->nsproxy->cgroup_ns; > + if (p->nsproxy) > + pcgn = p->nsproxy->cgroup_ns; > + if (ccgn != pcgn) > + return -EACCES; > + > + ccred = current_real_cred(); > + pcred = rcu_dereference_protected(p->real_cred, 1); > + > + if (ccred->user_ns != pcred->user_ns) > + return -EACCES; > + if (task_active_pid_ns(current) != task_active_pid_ns(p)) > + return -EACCES; > + return 0; > +}