Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp958094ybi; Thu, 30 May 2019 09:16:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqxFEGCS/q0Wsrvsl2uY4qZWzGx6qbpuSCTw+5nW/USx2w6jcmQ/UkJohOEZ0SaWUT2q5IEh X-Received: by 2002:a63:184:: with SMTP id 126mr4385512pgb.420.1559233007407; Thu, 30 May 2019 09:16:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559233007; cv=none; d=google.com; s=arc-20160816; b=xly7708dzKOYT88PulMdsm+Ywp9tJ7L2VFUwOWF5sF+H09RI6DeZbrT5o+QsOqTNYO YZ5m0BpkCokoIwpZ1JkJFB5zCbmkvomGjMoZOhpLSJjNaHtqQZimn8GKLaIPf2we8VKa DD+6/97DD8wYiBmr/CU2XlJHnhoiZpvUFYx4SQm4myNpg5VtItBAvKx+71a1KdEwimDl s0f+lk354vgyQ1cyLg4s6YVTT5it1QXv/ukekwLJzGkpTyx8piJHx25vEDXDl6coMtJQ CeepRdS3cgUaf2OSpf/NXmtOdEOlz4jV2pyFoTvOMKre2ykwfTTXEpqiAAtvoQ0t1bvz 6qYA== 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; bh=7se1llaI0TLWvUA7wkXSq6szfBNMTtJn6RjX4oq61I0=; b=VyN0U0/zSDIne0fEY8ERSIUPGX/p3eubkI0xZwQXzahBl8H7rfX9Z74oxgbV2qeRXa liRhU48YBfqDGFy5Qbmb++t+J8r4LhdzGQ7reMZXr2bD5MhSM5lPPtcNTGc13jacmWgU IdRZ0rvRfMpIuJrbT4AzLfUGqDYbVcLRLcs8AILFiggFVMlBvZQ6YCoMWGmC0UesRO21 B2av68P6zJDaTyogi5ckt8V5Y2R2EGawdZDkUKzp0Wv14uHFBvDHYS0vLHWRwSsRkvSd GKzEZNmPIqWmbZuqS5LnkmG4oUvEti7fxCyapknAu9Id4GZ19gJdPxNzaHOxPUAOURT0 5Ekg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VCnboiF8; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r25si3407457pgv.333.2019.05.30.09.16.29; Thu, 30 May 2019 09:16:47 -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=@kernel.org header.s=default header.b=VCnboiF8; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727696AbfE3QO0 (ORCPT + 99 others); Thu, 30 May 2019 12:14:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:58032 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727418AbfE3QOZ (ORCPT ); Thu, 30 May 2019 12:14:25 -0400 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 CB6A125D96 for ; Thu, 30 May 2019 16:14:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559232864; bh=1s8Cs2JQUU40YRbwjNco7sbSB4A0GwXuuKK25BIeJkI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=VCnboiF82xTt7afpDzh2drPNaR0hSnvkhXzqo7HzeDBqDcCyifW0ENfGgnDFO54bi PY1AbT4sAPpLgBcGQUhJBYLnq0+I2h8LQpsKq0TYyG9FWXDYvf6TQnd1O97R/MorgT L5bSZn9zL8wvLXCM8h/UfiuF6xtVTrNRuMhe8ddI= Received: by mail-wr1-f51.google.com with SMTP id w13so4565633wru.11 for ; Thu, 30 May 2019 09:14:23 -0700 (PDT) X-Gm-Message-State: APjAAAVNC84KPX1YBaMaYDPe0dMfk5Rd7XLnZU6I1YVta6cvT5cWJCdC g1Q+0RaeiL8IZ6LYSvOJurxV8wWKROVakZ2DP9a6Qw== X-Received: by 2002:adf:fe90:: with SMTP id l16mr3106260wrr.221.1559232862193; Thu, 30 May 2019 09:14:22 -0700 (PDT) MIME-Version: 1.0 References: <20190524175458.GB365@linux.intel.com> <960B34DE67B9E140824F1DCDEC400C0F654E8E1D@ORSMSX116.amr.corp.intel.com> <20190524200333.GF365@linux.intel.com> <20190524224107.GJ365@linux.intel.com> <683B5E3D-AFB6-4B45-8D39-B00847312209@amacapital.net> <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> In-Reply-To: From: Andy Lutomirski Date: Thu, 30 May 2019 09:14:10 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) To: Stephen Smalley Cc: Andy Lutomirski , "Xing, Cedric" , "Christopherson, Sean J" , 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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > > - 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. > > > > > And I have two design proposals. One is static and one is dynamic. > > To implement either one, we will probably need a new .may_mprotect vm > > operation, and that operation can call an LSM hook. Or we can give > > LSMs a way to detect that a given vm_area_struct is an enclave. As I > > see it, this is an implementation detail that is certainly solveable. > > > > > > Static proposal: > > > > > > EADD takes an execute_intent flag. It calls a new hook: > > > > int security_enclave_load(struct vm_area_struct *source, bool execute_intent); > > > > This hook will fail if execute_intent==true and the caller has neither > > EXECUTE, EXECMOD, nor EXECMEM. > > EADD execute_intent flag is originally provided by whom (userspace or > driver) on what basis? Which file is referenced by source->vm_file? Why > trigger all three checks up front versus only checking if needed? Won't > this trigger a lot of unnecessary EXECMOD and EXECMEM denials that will > need to be dontaudit'd? What if there is a mismatch between > execute_intent and the initial permissions? It's provided by userspace based on whether it thinks the data in question is enclave code. source->vm_file is the file from which the code is being loaded. I'm assuming that the user code will only set excute_intent ==true if it actually wants to execute the code, so, if there's a denial, it will be fatal. The normal case will be that the request will be granted on the basis of EXECUTE. > > > > > EAUG sets execute_intent = false. > > > > EINIT takes a sigstruct pointer. SGX can (when initially upstreamed > > or later on once there's demand) call a new hook: > > > > security_enclave_init(struct sigstruct *sigstruct, struct > > vm_area_struct *source); > > Is struct sigstruct the same as struct sgx_sigstruct in the current > patches (i.e. just the sigstruct data, no file)? What file is > referenced by source->vm_file (the sigstruct or the enclave or > /dev/sgx/enclave)? Is this hook only for enforcing a whitelist on what > enclaves can be loaded? What is the target of the check? sigstruct is just the data. source->vm_file is the file from which the sigstruct came, which could be a .sigstruct file or could be the main executable or a DSO that contains an embedded enclave. The sigstruct data is there so that an LSM (not necessarily SELinux) could check MRENCLAVE or MRSIGNER, and the source is there so that the file's label can be checked. > > > mmap() and mprotect() will require EXECMEM to create WX or RWX > > mappings. They will require EXECMOD to create RX or X mappings of an > > execute_intent==false page. They require no permissions in the other > > cases. > > Does this occur for both setting initial permissions and runtime > permissions or just runtime? Both userspace- and driver-initiated > mmap/mprotect operations or just userspace-initiated ones? Does the > driver use interfaces that call the mmap/mprotect hooks or lower level > functions? These would occur for any mmap(), mprotect(), or ioctl() that changes VMA permissions. Actually arranging for the hooks to be called is an implementation detail that might require a new .mprotect vm_operation. As an alternative, security_enclave_init() or similar could supply may_execmod and may_execmem flags to the driver, and the driver could do these checks on its own when mmap() and mprotect() happen without a new LSM callback. > > > > > > > Dynamic proposal: > > > > > > EADD does not take any special flags. It does something like this internally: > > > > bool execute_intent = true; > > int security_enclave_load(struct vm_area_struct *source, bool > > *execute_intent); > > > > The implementation of security_enclave_load() may set *execute_intent to false. > > The driver records execute_intent after the LSM is done. > > On what basis does LSM decide whether to set *execute_intent? If the > process lacks all three permissions? What if there is a mismatch with > the initial permissions? > I think it would set *execute_intent=false if the process lacks EXECUTE on source->vm_file. I'm not sure any more complexity is required. If the enclave has EXECMOD, then it will still work on the basis of the mmap/mprotect rules. > > > > mmap() and mprotect() will require EXECMEM to create WX or RWX > > mappings. They will require EXECMOD to create RX or X mappings of an > > execute_intent==false page. They require no permissions in the other > > cases. > > > > > > > > A benefit of the static proposal is that audit failures due to a lack > > of EXECUTE permission are easy to implement and to understand in the > > lods. With the dynamic model, we can only really audit the lack of > > EXECMOD or EXECMEM. A benefit of the dynamic model is that we hide > > what is arguably a decently large wart from the API. > > >