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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_HK_NAME_DR,USER_AGENT_MUTT autolearn=unavailable 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 CE533C28CC7 for ; Mon, 3 Jun 2019 09:15:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B22BC27F21 for ; Mon, 3 Jun 2019 09:15:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728838AbfFCJN1 (ORCPT ); Mon, 3 Jun 2019 05:13:27 -0400 Received: from wind.enjellic.com ([76.10.64.91]:34382 "EHLO wind.enjellic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727961AbfFCJN1 (ORCPT ); Mon, 3 Jun 2019 05:13:27 -0400 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.15.2/8.15.2) with ESMTP id x539C8O2013972; Mon, 3 Jun 2019 04:12:08 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.15.2/8.15.2/Submit) id x539C6Fb013971; Mon, 3 Jun 2019 04:12:06 -0500 Date: Mon, 3 Jun 2019 04:12:06 -0500 From: "Dr. Greg" To: Sean Christopherson Cc: Andy Lutomirski , Stephen Smalley , "Xing, Cedric" , William Roberts , Jarkko Sakkinen , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Eric Paris , "selinux@vger.kernel.org" , Jethro Beekman , "Hansen, Dave" , Thomas Gleixner , Linus Torvalds , LKML , X86 ML , "linux-sgx@vger.kernel.org" , Andrew Morton , "nhorman@redhat.com" , "npmccallum@redhat.com" , "Ayoun, Serge" , "Katz-zamir, Shay" , "Huang, Haitao" , Andy Shevchenko , "Svahn, Kai" , Borislav Petkov , Josh Triplett , "Huang, Kai" , David Rientjes Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) Message-ID: <20190603091206.GA13614@wind.enjellic.com> Reply-To: "Dr. Greg" References: <960B34DE67B9E140824F1DCDEC400C0F654EB487@ORSMSX116.amr.corp.intel.com> <678a37af-797d-7bd5-a406-32548a270e3d@tycho.nsa.gov> <20190530180110.GB23930@linux.intel.com> <20190530211645.GB27551@linux.intel.com> <20190530213601.GC27551@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190530213601.GC27551@linux.intel.com> User-Agent: Mutt/1.4i X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [127.0.0.1]); Mon, 03 Jun 2019 04:12:08 -0500 (CDT) Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Thu, May 30, 2019 at 02:36:01PM -0700, Sean Christopherson wrote: Good morning, I hope everyone had a pleasant weekend. > Assuming MRENCLAVE generated by Graphene or any other hosting scheme > are stable[1], then avoiding EXEC means the user can > effectively whitelist what enclaves are runnable by Graphene, even > if the kernel doesn't implement security_enclave_create/init(). > > I agree that it probably isn't all that important, it's more of a > "why not" argument, i.e. what is gained by not using sigstruct as a > proxy? > > [1] What in the world is being attested if MRENCLAVE isn't stable? The cryptographic identity of the entity that signed the enclave and generated the SIGSTRUCT. At the risk of being the monotone in the choir, any relevant SGX security controls require verifying the identity of whoever signed the identity characteristics (SIGSTRUCT) of the image that initiates the execution of an SGX TEE. Other then verifying the initial execution image, the MRENCLAVE value isn't all that relevant. This issue is further evidenced by the fact that sealing data to an enclave uses the MRSIGNER variant of ENCLU[EGETKEY] key derivation. The current work on LSM controls seems to focus on the identity of the entity that is requesting the image to be loaded rather then who actually signed, and presumably authored, the code. As I have previously noted, with SGX2/EDMM, a platform owner may not even have any visibility into the code that an SGX TEE may ultimately load and execute. Any security relevant LSM control in this space has to focus on providing the platform owner the ability to take action based on the contents of the SIGSTRUCT of the initiating image. In addition to the identity of who is requesting the image to be loaded. Have a good week. Dr. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "Experience is something you don't get until just after you need it." -- Olivier