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, URIBL_BLOCKED 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 7C9FEC04AB4 for ; Thu, 16 May 2019 21:00:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4C6FD2168B for ; Thu, 16 May 2019 21:00:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558040429; bh=Z9A5Gn8IYTN5zojnjOV85wLmycj3ctbS4IY7KKu9Mag=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=p2tIBXnY3fG1wYrxdpzghBkiPleIG/WGEUhz3/pN1WmmSCHO89UVBUtg+qkIMopdx nOk7gWsIIbIOOktKUwDJDm8f7/Nu9yTgYFJtiS/5/wh9oiXgwunqz6skGa89Tj44bO a+kP/VjG91diLO6v8ADa0LSjYLmt/HEPuN43At3A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728188AbfEPVA2 (ORCPT ); Thu, 16 May 2019 17:00:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:51634 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728184AbfEPVA2 (ORCPT ); Thu, 16 May 2019 17:00:28 -0400 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.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 0D9FB21473 for ; Thu, 16 May 2019 21:00:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558040427; bh=Z9A5Gn8IYTN5zojnjOV85wLmycj3ctbS4IY7KKu9Mag=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=a7BgMrGtgZnxHAYWSt6S3/k/FkXM/xyFOY56aB6mNWaH59iedF30vLtmnsAne7bNK pKHgIPsdDoRnyTfZ8983ZTrMtZJvfYHnnPark1FEHJRh/BhMHtCldpFwiRsbWhGsNc nwnxYdF8x9KNOmpmWOAp4pzRESsYLYIpNOTVGbtY= Received: by mail-wm1-f50.google.com with SMTP id 15so743179wmg.5 for ; Thu, 16 May 2019 14:00:26 -0700 (PDT) X-Gm-Message-State: APjAAAXVgsJBiwSKYHRyLRsM01/xTosLedOxIIND0D0EWehSF0wdKPgx KcAA3RwG7OiUGXFZ8lAimYbCMXiR03xMXnCv5QDmQg== X-Google-Smtp-Source: APXvYqxyFCPtUJy1tK3AM0Pm9A3oAjys0XNTVLpwx7SvFZrupH0Xadu93+oLK89qkXjq20GSFTKUjie9fJ9+xPJMs2o= X-Received: by 2002:a1c:9689:: with SMTP id y131mr30689877wmd.74.1558040425543; Thu, 16 May 2019 14:00:25 -0700 (PDT) MIME-Version: 1.0 References: <8fe520bb-30bd-f246-a3d8-c5443e47a014@intel.com> <358e9b36-230f-eb18-efdb-b472be8438b4@fortanix.com> <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> In-Reply-To: From: Andy Lutomirski Date: Thu, 16 May 2019 14:00:13 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) To: James Morris Cc: Andy Lutomirski , Sean Christopherson , "Serge E. Hallyn" , LSM List , Paul Moore , Stephen Smalley , Eric Paris , selinux@vger.kernel.org, Jarkko Sakkinen , 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" Content-Transfer-Encoding: quoted-printable Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: > On May 16, 2019, at 12:24 AM, James Morris wrote: > >> On Wed, 15 May 2019, Andy Lutomirski wrote: >> >>> On Wed, May 15, 2019 at 3:46 PM James Morris wrote: >>> >>> You could try user.sigstruct, which does not require any privs. >>> >> >> I don't think I understand your proposal. What file would this >> attribute be on? What would consume it? > > It would be on the enclave file, so you keep the sigstruct bound to it, > rather than needing a separate file to manage. It would simplify any LSM > policy check. > > It would be consumed by (I guess) the SGX_INIT_THE_ENCLAVE ioctl in your > example, instead of having a 2nd fd. > > Okay, I think I see what you=E2=80=99re suggesting. I don=E2=80=99t think i= t works well, though, since loading the data from the enclave file will almost always be done in multiple chunks, and it=E2=80=99s not clear when the kern= el should look for the xattr or what to do if the xattr changes part way through.