From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 712C2C7618F for ; Mon, 15 Jul 2019 22:29:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 478052086C for ; Mon, 15 Jul 2019 22:29:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563229777; bh=1o/MhE8wLDRGugzlRBNF+fQFZHSjqcfwu7zrwe+cre8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=ugbN1DEu0yBa9ydIugGEoBvNDPuhMgRRwhhVi0FlN3rpNxxLW0bySuEvDsUh0lIip 5AvTGV2UZtlyAWGBGBrwAzxKeL5oiqjr8dbopNTPVJnOXd3TQIJ49JRDjRQCi+B/CS Z9jTm49DeI140/qRNkOH1wC+vwpmo48+Otaea8cA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731223AbfGOW3g (ORCPT ); Mon, 15 Jul 2019 18:29:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:44978 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731145AbfGOW3g (ORCPT ); Mon, 15 Jul 2019 18:29:36 -0400 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7FAEA21743 for ; Mon, 15 Jul 2019 22:29:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563229775; bh=1o/MhE8wLDRGugzlRBNF+fQFZHSjqcfwu7zrwe+cre8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZpDkylhailMnpdRsfDMZ9sgx/6WEvUFf2W1QdSbfg4+IbzCmjlQLl1e7CWFk0vulR pHQIxZkjMsk9EwsDA66rGR/qXwTfDqrYaTo/8NHMSyKlaer43RgO+s+jJGyz/yxkU3 KpksNaWKviuwgv0NXhFqVRCJcyvaqIDpnSvfUsts= Received: by mail-wm1-f42.google.com with SMTP id s15so16703589wmj.3 for ; Mon, 15 Jul 2019 15:29:35 -0700 (PDT) X-Gm-Message-State: APjAAAULGH/PDB6/QnVOETfZoIdMJ/ijq46OsitMMJKem6KxLUq2HocX NllyOk9HlNZjoy77v3syYcxiKl/xFVBV4cUnJ6fCcw== X-Google-Smtp-Source: APXvYqwrGgYmx1u4B6STzlyQ0IXuhijCGw7k58WoJIe8fye9JZ3JBNz6Xc04hL1kryvhnKuWBaLSrjJHUIzF81iDO7I= X-Received: by 2002:a1c:c5c2:: with SMTP id v185mr27926618wmf.161.1563229773990; Mon, 15 Jul 2019 15:29:33 -0700 (PDT) MIME-Version: 1.0 References: <20190617222438.2080-1-sean.j.christopherson@intel.com> <20190617222438.2080-5-sean.j.christopherson@intel.com> <20190619152018.GC1203@linux.intel.com> <20190620221702.GE20474@linux.intel.com> <20190707190809.GE19593@linux.intel.com> <1b7369a08e98dd08a4f8bb19b16479f12bee130f.camel@linux.intel.com> <20190708161932.GE20433@linux.intel.com> <20190709160634.3yupyabf5svnj4ds@linux.intel.com> <20190710172553.GE4348@linux.intel.com> In-Reply-To: <20190710172553.GE4348@linux.intel.com> From: Andy Lutomirski Date: Mon, 15 Jul 2019 15:29:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits To: Sean Christopherson , "Schaufler, Casey" , James Morris Cc: Jarkko Sakkinen , linux-sgx@vger.kernel.org, Dave Hansen , Cedric Xing , Andy Lutomirski , Jethro Beekman , "Dr . Greg Wettstein" , Stephen Smalley , LSM List Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Wed, Jul 10, 2019 at 10:25 AM Sean Christopherson wrote: > > On Tue, Jul 09, 2019 at 07:06:34PM +0300, Jarkko Sakkinen wrote: > > On Mon, Jul 08, 2019 at 09:19:32AM -0700, Sean Christopherson wrote: > > > > 2. Probably some "user story" type of examples would help with the > > > > discussion overall [1] i.e. how one would use this for > > > > her own good. > > > > > > The compelling story is Andy's original concern that userspace could > > > circumvent existing security policies by running code in an enclave. > > > > > > AIUI, closing the LSM loophole is the minimal requirement to get SGX > > > upstreamed. The extensive discussion has largely been focused on > > > ensuring that whatever mechanism is used to close the loophole will > > > play nice with future SGX functionality and/or LSM security policies. > > > > OK, might be getting here where I fall out of the wagon so: > > > > Doesn't Andy's example anyway require a process that has privileges to > > make pages executable i.e. it could run arbitrary code even without an > > enclave? > > Ah, no. He did raise that concern, but it'd only be an issue if the > enclave fd were backed by an anon inode, in which case all enclaves would > need EXECMEM in order to gain PROT_EXEC on EPC. Because the fd is backed > /dev/sgx/enclave, userspace just needs FILE__EXECUTE on /dev/sgx/enclave. I would say it differently: regardless of exactly how /dev/sgx/enclave is wired up under the hood, we want a way that a process can be granted permission to usefully run enclaves without being granted permission to execute whatever bytes of code it wants. Preferably without requiring LSMs to maintain some form of enclave signature whitelist. This is pretty much the only hard requirement I see. We really could achieve this, in a somewhat limited form, by saying that LSMs can approve or reject the SIGSTRUCT. But doing it that way is a bit nasty as we've noticed, for a few reasons. Several of you have raised objections to requiring SIGSTRUCT to come from a .sigstruct file. We also need to worry about a SIGSTRUCT that refers to an enclave that forgot to measure its text. And we need to worry about SGX2. So this whole messy exercise boils down to: a bunch of security policy authors think that EXECMEM and similar are not to be given out lightly. How to we allow policies like that to be compatible with SGX?