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=-6.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 E69F4C04AAF for ; Thu, 16 May 2019 21:03:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A5E6020881 for ; Thu, 16 May 2019 21:03:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558040593; bh=NO9G06JDTnmk7v8QHSnoMAUvRcyj/9lnX0RTiqK+xcY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=1xY8lRrqqxb9zKNWMJ6CNI5H6SFYIGf2kBQ8bDJ7g3Zq7JNO/TdTkG6cj/KTQIBIv NaU3bkUcdq29FMsIDKmX7YN4+3+2D4LvMofjHNqeD63GuTI7ouXUTCvthRnAlIXMW1 34ZgLoEV8rkLEpRe13IyxlJ/SZJf/0UtT99t9P6o= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727951AbfEPVDN (ORCPT ); Thu, 16 May 2019 17:03:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:52714 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726937AbfEPVDN (ORCPT ); Thu, 16 May 2019 17:03:13 -0400 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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 6B3B521773 for ; Thu, 16 May 2019 21:03:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558040591; bh=NO9G06JDTnmk7v8QHSnoMAUvRcyj/9lnX0RTiqK+xcY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Qn7kjHIprHMIS5LUTr8DlWiUs+osDXQecSfgGM4n7WqcqzpD718QXoaxS8kRobOec p7pxTTETmQDT/VHTsiOwVaDRH2dnZiltdz2QtPSWvKSkZwTjDoDEPK75R1gibc/AGc qn6Sby9LWJHIyRlmObLu5cGyHe1fDjUOzWX+Ka3A= Received: by mail-wr1-f50.google.com with SMTP id h4so4861585wre.7 for ; Thu, 16 May 2019 14:03:11 -0700 (PDT) X-Gm-Message-State: APjAAAX8JqHpdqAtsS88HzJbJo630YwHXKIdlVXZhpZJvGBWWJhiq77f cYNUGu1BsXvW24v691iFWO4IRm+gIzDmuMnM+W8Acw== X-Google-Smtp-Source: APXvYqw1dYL01R+yjYjXnMkrG9YAOWLpm6jqnGKsVqFBcfXTj/mj24TqIWVrjrQnLHUKSSXbH0gRw3flducq2vGagig= X-Received: by 2002:a5d:45c7:: with SMTP id b7mr9091972wrs.176.1558040589844; Thu, 16 May 2019 14:03:09 -0700 (PDT) MIME-Version: 1.0 References: <960B34DE67B9E140824F1DCDEC400C0F4E886094@ORSMSX116.amr.corp.intel.com> <6da269d8-7ebb-4177-b6a7-50cc5b435cf4@fortanix.com> <20190513102926.GD8743@linux.intel.com> <20190514104323.GA7591@linux.intel.com> <20190514204527.GC1977@linux.intel.com> <20190515013031.GF1977@linux.intel.com> <20190516051622.GC6388@linux.intel.com> In-Reply-To: <20190516051622.GC6388@linux.intel.com> From: Andy Lutomirski Date: Thu, 16 May 2019 14:02:58 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) To: Jarkko Sakkinen Cc: Andy Lutomirski , Sean Christopherson , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Stephen Smalley , Eric Paris , selinux@vger.kernel.org, Jethro Beekman , "Xing, Cedric" , "Hansen, Dave" , Thomas Gleixner , "Dr. Greg" , 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 Content-Type: text/plain; charset="UTF-8" Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org > On May 15, 2019, at 10:16 PM, Jarkko Sakkinen wrote: > >> On Wed, May 15, 2019 at 11:27:04AM -0700, Andy Lutomirski wrote: >> Hi, LSM and SELinux people- >> >> We're trying to figure out how SGX fits in with LSMs. For background, >> an SGX library is functionally a bit like a DSO, except that it's >> nominally resistant to attack from outside and the process of loading >> it is complicated. To load an enclave, a program can open >> /dev/sgx/enclave, do some ioctls to load the code and data segments >> into the enclave, call a special ioctl to "initialize" the enclave, >> and then call into the enclave (using special CPU instructions). >> >> One nastiness is that there is not actually a universally agreed upon, >> documented file format for enclaves. Windows has an undocumented >> format, and there are probably a few others out there. No one really >> wants to teach the kernel to parse enclave files. >> >> There are two issues with how this interacts with LSMs: >> >> 1) LSMs might want to be able to whitelist, blacklist, or otherwise >> restrict what enclaves can run at all. The current proposal that >> everyone seems to dislike the least is to have a .sigstruct file on >> disk that contains a hash and signature of the enclave in a >> CPU-defined format. To initialize an enclave, a program will pass an >> fd to this file, and a new LSM hook can be called to allow or disallow >> the operation. In a SELinux context, the idea is that policy could >> require the .sigstruct file to be labeled with a type like >> sgx_sigstruct_t, and only enclaves that have a matching .sigstruct >> with such a label could run. > > Similarly if we could take data for the enclave from fd and enforce > it with sgx_enclave_t label. That certainly *could* be done, and I guess the decision could be left to the LSMs, but I'm not convinced this adds value. What security use case does this cover that isn't already covered by requiring EXECUTE (e.g. lib_t) on the enclave file and some new SIGSTRUCT right on the .sigstruct? > >> Here's a very vague proposal that's kind of like what I've been >> thinking over the past few days. The SGX inode could track, for each >> page, a "safe-to-execute" bit. When you first open /dev/sgx/enclave, >> you get a blank enclave and all pages are safe-to-execute. When you >> do the ioctl to load context (which could be code, data, or anything >> else), the kernel will check whether the *source* VMA is executable >> and, if not, mark the page of the enclave being loaded as unsafe. >> Once the enclave is initialized, the driver will clear the >> safe-to-execute bit for any page that is successfully mapped writably. > > With the fd based model for source I'd mark SECINFO.W pages as unsafe > to execute and then check unsafe bit before applying lets say EMODT > or EMODPR. > > There is a problem here though. Usually the enclave itself is just a > loader that then loads the application from outside source and creates > the executable pages from the content. > > A great example of this is Graphene that bootstraps unmodified Linux > applications to an enclave: > > https://github.com/oscarlab/graphene > ISTM you should need EXECMEM or similar to run Graphene, then.