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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH, 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 5169EC28CC0 for ; Thu, 30 May 2019 19:21:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 14B47260C5 for ; Thu, 30 May 2019 19:21:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559244061; bh=Odh5mJR7Qgs8tP+o4xgz7GTPiNe9Lb/ibVAyREXQGqQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=cOPyS17Y9GJtWoRyE6VR1T1dMGVbt0CT3H/Ii8yKP9x8RblmXeA7/KU/9ySmOv4dc Fcqvt9dYi9gHxn56K8wHEAPW6szzcYJ4g1VCZmjKd5Wrn6HRvK3Jy3gedik9yHFfwa OVhW83X2SlRuas9oPWsc0OMracl/jFvF9bURm3/U= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725913AbfE3TVA (ORCPT ); Thu, 30 May 2019 15:21:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:59722 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726031AbfE3TVA (ORCPT ); Thu, 30 May 2019 15:21:00 -0400 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.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 D970F260CC for ; Thu, 30 May 2019 19:20:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559244059; bh=Odh5mJR7Qgs8tP+o4xgz7GTPiNe9Lb/ibVAyREXQGqQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=k1VTA2qU/RD8Hs7QLYGbUetg3lfpgX8214GkgLedrTURhqCoR0r7gjkRxDYxxEonb gTc8bbpVFJ7fgrtdK662jLwj7iXrBIGIuLY91PlWLaVSKxh9ozJOy21jpK7qOpAcQg 6IAmBphU87+WYP27EHkPfBt4ShDmO/Guk3AeZ7dk= Received: by mail-wr1-f42.google.com with SMTP id m3so4933126wrv.2 for ; Thu, 30 May 2019 12:20:58 -0700 (PDT) X-Gm-Message-State: APjAAAVZj8YrG1lbmCSvLsTLVid9L3GEipXwaFAXjN6P8KT1YoLGq9QG ndOGaINa2UBODT0H73xhwo5Iv70Bny7lL/JifyN+0Q== X-Google-Smtp-Source: APXvYqy73ZMq0qQmmQ/+vAioP4b3Sl7JgF5MBuyujqDcT8diOwfoebNcCtYnbTp7wfhGb0A0cPCz00xyeb2Lc9Xg3WE= X-Received: by 2002:a5d:6207:: with SMTP id y7mr3442998wru.265.1559244057293; Thu, 30 May 2019 12:20:57 -0700 (PDT) MIME-Version: 1.0 References: <960B34DE67B9E140824F1DCDEC400C0F654E965F@ORSMSX116.amr.corp.intel.com> <960B34DE67B9E140824F1DCDEC400C0F654E9824@ORSMSX116.amr.corp.intel.com> <20190528202407.GB13158@linux.intel.com> <285f279f-b500-27f0-ab42-fb1dbcc5ab18@tycho.nsa.gov> <960B34DE67B9E140824F1DCDEC400C0F654EB487@ORSMSX116.amr.corp.intel.com> <678a37af-797d-7bd5-a406-32548a270e3d@tycho.nsa.gov> <20190530180110.GB23930@linux.intel.com> In-Reply-To: <20190530180110.GB23930@linux.intel.com> From: Andy Lutomirski Date: Thu, 30 May 2019 12:20:45 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) 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 , "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 Thu, May 30, 2019 at 11:01 AM Sean Christopherson wrote: > > On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote: > > On Thu, May 30, 2019 at 8:04 AM Stephen Smalley wrote: > > > > > > On 5/30/19 10:31 AM, Andy Lutomirski wrote: > > > > Hi all- > > > > > > > > After an offline discussion with Sean yesterday, here are some updates > > > > to the user API parts of my proposal. > > > > > > > > Unfortunately, Sean convinced me that MAXPERM doesn't work the way I > > > > described it because, for SGX2, the enclave loader won't know at load > > > > time whether a given EAUG-ed page will ever be executed. So here's an > > > > update. > > > > > > > > First, here are the requrements as I see them, where EXECUTE, EXECMOD, > > > > and EXECMEM could be substituted with other rules at the LSM's > > > > discretion: > > > > > > > > - You can create a WX or RWX mapping if and only if you have EXECMEM. > > > > > > > > - To create an X mapping of an enclave page that has ever been W, you > > > > need EXECMOD. > > > > > > EXECMOD to what file? The enclave file from which the page's content > > > originated, the sigstruct file, or /dev/sgx/enclave? > > > > I leave that decision to you :) The user should need permission to do > > an execmod thing on an enclave, however that wants to be encoded. > > But that decision dictates how the SGX API handles sigstruct. If LSMs > want to associate EXECMOD with sigstruct, then SGX needs to take sigstruct > early and hold a reference to the file for the lifetime of the enclave. > And if we're going to do that, the whole approach of inheriting > permissions from source VMAs becomes unnecessary complexity. > > > > > > > > - To create an X mapping of an enclave page that came from EADD, you > > > > need EXECUTE on the source file. Optionally, we could also permit > > > > this if you have EXECMOD. > > > > > > What is the "source file" i.e. the target of the check? Enclave file, > > > sigstruct file, or /dev/sgx/enclave? > > > > Enclave file -- that is, the file backing the vma from which the data is loaded. > > It wasn't explicitly called out in Andy's proposal(s), but the idea is > that the SGX driver would effectively inherit permissions from the source > VMA (EADD needs a source for the initial value of the encave page). I actually meant for it to *not* work like this. I don't want the source VMA to have to be VM_EXEC. I think the LSM should just check permissions on ->vm_file.