* Re: [RFC PATCH v3 09/12] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX [not found] ` <alpine.LRH.2.21.1906200702040.28119@namei.org> @ 2019-06-23 17:16 ` Dr. Greg 2019-06-26 20:39 ` James Morris 0 siblings, 1 reply; 8+ messages in thread From: Dr. Greg @ 2019-06-23 17:16 UTC (permalink / raw) To: James Morris Cc: Jarkko Sakkinen, Sean Christopherson, linux-sgx, Dave Hansen, Cedric Xing, Andy Lutomirski, Jethro Beekman, Stephen Smalley, casey.schaufler, william.c.roberts, linux-security-module, selinux On Thu, Jun 20, 2019 at 07:13:50AM +1000, James Morris wrote: Good morning, I hope the weekend has been going well for everyone. > On Wed, 19 Jun 2019, Jarkko Sakkinen wrote: > > > Can LSM callbacks ever non-generic when it comes to hardware? This is > > the very first time I ever see such callbacks being introduced. > > > > I suspect that from maintainers perspective, accepting such changes for > > Intel hardware, could open a pandoras box. > If there's a major distro/userbase committing to ship with these > hooks enabled via a supported in-tree LSM, the case for inclusion is > clear. I see that Jarkko responded down thread that there may be a major distribution already committed to SGX specific LSM hooks. My apologies for providing these reflections if that is the case and there is some type of 'deal' in place with respect to all of this. > If the hooks could be generalized beyond just SGX, that would be > ideal, but it's not clear if that's feasible. We believe there is some degree of commonality that can be addressed with respect to implementing LSM enforcement over SGX enclaves. However, big picture, here is the challenge that we see with respect to these conversations surrounding the integration of the SGX driver with the LSM: As a technology, SGX was designed to enable software to protect itself from an adversarial operating system and hardware platform. Given that, if we are intellectually honest, how effective can the LSM/OS be with respect to controlling the actions of an enclave? Without question, being able to regulate and control which identities can intersect to load executable content into an enclave is important. All of the infrastructure appears to be already there to accomplish that, given the default model of a shared library implementation of an enclave and requiring the loader to mmap file backed TEXT pages RX. The most relevant and important control with respect to whether or not an enclave should be allowed to execute is evaluation of the SIGSTRUCT. Given the trajectory that platform security is on, SGX is not going to be the last technology of its type nor the only technology that makes use of cryptographically based code provenance. As a result, if we are content with handing an opaque pointer of a descriptive struture to an LSM routine, a generic hook that is tasked with verifying code or execution environment provenance doesn't seem like it would need to be technology specific nor controversial. That leaves as the last thorny issue the question of dynamic allocation of memory for executable content. As we have stated before, and at the outset of this note, from a security perspective this is only, effectively, a binary question for the platform owner as to whether or not the concept should be allowed. A generic LSM hook, appropriately named, could execute that decision without being SGX specific. Arguably, the hook should be named to indicate that it is seeking approval for allocating memory to be used for anonymous executable content, since that is what it would be effectively requesting approval for, in the case of SGX. For completeness a third generic hook may be useful. The purpose of that hook would be to verify a block of memory as being measured or signed for consideration as executable content. Arguably that will have utility far beyond SGX. In the case of SGX it would address the issue as to whether or not a block of executable content in untrusted space is eligible for anonymous execution. That may be a useful security measure in order to provide some control over an enclave being used as a random execution oracle. It obviously has no security utility against the enclave author since, as we have noted before, it is possible for the enclave author to simply pull whatever code is desired over an encrypted network connection. > James Morris Hopefully these comments are a useful basis for further discussion. Best wishes for a productive week to everyone. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker IDfusion, LLC 4206 N. 19th Ave. Implementing measured information privacy Fargo, ND 58102 and integrity architectures. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: gw@idfusion.org ------------------------------------------------------------------------------ "My thoughts on trusting Open-Source? A quote I once saw said it best: 'Remember, Amateurs built the ark. Professionals built the Titanic.' Perhaps most significantly the ark was one guy, there were no doubt committees involved with the Titanic project." -- Dr. G.W. Wettstein Resurrection ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH v3 09/12] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX 2019-06-23 17:16 ` [RFC PATCH v3 09/12] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX Dr. Greg @ 2019-06-26 20:39 ` James Morris 0 siblings, 0 replies; 8+ messages in thread From: James Morris @ 2019-06-26 20:39 UTC (permalink / raw) To: Dr. Greg Cc: Jarkko Sakkinen, Sean Christopherson, linux-sgx, Dave Hansen, Cedric Xing, Andy Lutomirski, Jethro Beekman, Stephen Smalley, casey.schaufler, william.c.roberts, linux-security-module, selinux On Sun, 23 Jun 2019, Dr. Greg wrote: > The most relevant and important control with respect to whether or not > an enclave should be allowed to execute is evaluation of the > SIGSTRUCT. Given the trajectory that platform security is on, SGX is > not going to be the last technology of its type nor the only > technology that makes use of cryptographically based code provenance. > > As a result, if we are content with handing an opaque pointer of a > descriptive struture to an LSM routine, a generic hook that is tasked > with verifying code or execution environment provenance doesn't seem > like it would need to be technology specific nor controversial. > > That leaves as the last thorny issue the question of dynamic > allocation of memory for executable content. As we have stated > before, and at the outset of this note, from a security perspective > this is only, effectively, a binary question for the platform owner as > to whether or not the concept should be allowed. > > A generic LSM hook, appropriately named, could execute that decision > without being SGX specific. Arguably, the hook should be named to > indicate that it is seeking approval for allocating memory to be used > for anonymous executable content, since that is what it would be > effectively requesting approval for, in the case of SGX. > > For completeness a third generic hook may be useful. The purpose of > that hook would be to verify a block of memory as being > measured or signed for consideration as executable content. Arguably > that will have utility far beyond SGX. > > In the case of SGX it would address the issue as to whether or not a > block of executable content in untrusted space is eligible for > anonymous execution. That may be a useful security measure in order > to provide some control over an enclave being used as a random > execution oracle. > > It obviously has no security utility against the enclave author since, > as we have noted before, it is possible for the enclave author to > simply pull whatever code is desired over an encrypted network > connection. > > > James Morris > > Hopefully these comments are a useful basis for further discussion. Thanks, this is helpful. -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <20190617222438.2080-5-sean.j.christopherson@intel.com>]
[parent not found: <dc3d59c2783ea81d85d4d447bd1a4a2d5fe51421.camel@linux.intel.com>]
[parent not found: <20190619152018.GC1203@linux.intel.com>]
[parent not found: <20190620221702.GE20474@linux.intel.com>]
[parent not found: <20190707190809.GE19593@linux.intel.com>]
[parent not found: <1b7369a08e98dd08a4f8bb19b16479f12bee130f.camel@linux.intel.com>]
[parent not found: <20190708161932.GE20433@linux.intel.com>]
[parent not found: <20190709160634.3yupyabf5svnj4ds@linux.intel.com>]
[parent not found: <20190710172553.GE4348@linux.intel.com>]
* Re: [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits [not found] ` <20190710172553.GE4348@linux.intel.com> @ 2019-07-15 22:29 ` Andy Lutomirski 2019-08-01 16:38 ` Jarkko Sakkinen 0 siblings, 1 reply; 8+ messages in thread From: Andy Lutomirski @ 2019-07-15 22:29 UTC (permalink / raw) To: Sean Christopherson, Schaufler, Casey, James Morris Cc: Jarkko Sakkinen, linux-sgx, Dave Hansen, Cedric Xing, Andy Lutomirski, Jethro Beekman, Dr . Greg Wettstein, Stephen Smalley, LSM List On Wed, Jul 10, 2019 at 10:25 AM Sean Christopherson <sean.j.christopherson@intel.com> wrote: > > On Tue, Jul 09, 2019 at 07:06:34PM +0300, Jarkko Sakkinen wrote: > > On Mon, Jul 08, 2019 at 09:19:32AM -0700, Sean Christopherson wrote: > > > > 2. Probably some "user story" type of examples would help with the > > > > discussion overall [1] i.e. how one would use this for > > > > her own good. > > > > > > The compelling story is Andy's original concern that userspace could > > > circumvent existing security policies by running code in an enclave. > > > > > > AIUI, closing the LSM loophole is the minimal requirement to get SGX > > > upstreamed. The extensive discussion has largely been focused on > > > ensuring that whatever mechanism is used to close the loophole will > > > play nice with future SGX functionality and/or LSM security policies. > > > > OK, might be getting here where I fall out of the wagon so: > > > > Doesn't Andy's example anyway require a process that has privileges to > > make pages executable i.e. it could run arbitrary code even without an > > enclave? > > Ah, no. He did raise that concern, but it'd only be an issue if the > enclave fd were backed by an anon inode, in which case all enclaves would > need EXECMEM in order to gain PROT_EXEC on EPC. Because the fd is backed > /dev/sgx/enclave, userspace just needs FILE__EXECUTE on /dev/sgx/enclave. I would say it differently: regardless of exactly how /dev/sgx/enclave is wired up under the hood, we want a way that a process can be granted permission to usefully run enclaves without being granted permission to execute whatever bytes of code it wants. Preferably without requiring LSMs to maintain some form of enclave signature whitelist. This is pretty much the only hard requirement I see. We really could achieve this, in a somewhat limited form, by saying that LSMs can approve or reject the SIGSTRUCT. But doing it that way is a bit nasty as we've noticed, for a few reasons. Several of you have raised objections to requiring SIGSTRUCT to come from a .sigstruct file. We also need to worry about a SIGSTRUCT that refers to an enclave that forgot to measure its text. And we need to worry about SGX2. So this whole messy exercise boils down to: a bunch of security policy authors think that EXECMEM and similar are not to be given out lightly. How to we allow policies like that to be compatible with SGX? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits 2019-07-15 22:29 ` [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits Andy Lutomirski @ 2019-08-01 16:38 ` Jarkko Sakkinen 2019-08-04 22:20 ` Andy Lutomirski 0 siblings, 1 reply; 8+ messages in thread From: Jarkko Sakkinen @ 2019-08-01 16:38 UTC (permalink / raw) To: Andy Lutomirski Cc: Sean Christopherson, Schaufler, Casey, James Morris, linux-sgx, Dave Hansen, Cedric Xing, Jethro Beekman, Dr . Greg Wettstein, Stephen Smalley, LSM List On Mon, Jul 15, 2019 at 03:29:23PM -0700, Andy Lutomirski wrote: > I would say it differently: regardless of exactly how /dev/sgx/enclave > is wired up under the hood, we want a way that a process can be > granted permission to usefully run enclaves without being granted > permission to execute whatever bytes of code it wants. Preferably > without requiring LSMs to maintain some form of enclave signature > whitelist. Would it be better to have a signer whitelist instead or some combination? E.g. you could whiteliste either by signer or enclave signature. /Jarkko ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits 2019-08-01 16:38 ` Jarkko Sakkinen @ 2019-08-04 22:20 ` Andy Lutomirski 2019-08-05 20:51 ` Jarkko Sakkinen 0 siblings, 1 reply; 8+ messages in thread From: Andy Lutomirski @ 2019-08-04 22:20 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Andy Lutomirski, Sean Christopherson, Schaufler, Casey, James Morris, linux-sgx, Dave Hansen, Cedric Xing, Jethro Beekman, Dr . Greg Wettstein, Stephen Smalley, LSM List On Thu, Aug 1, 2019 at 9:38 AM Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote: > > On Mon, Jul 15, 2019 at 03:29:23PM -0700, Andy Lutomirski wrote: > > I would say it differently: regardless of exactly how /dev/sgx/enclave > > is wired up under the hood, we want a way that a process can be > > granted permission to usefully run enclaves without being granted > > permission to execute whatever bytes of code it wants. Preferably > > without requiring LSMs to maintain some form of enclave signature > > whitelist. > > Would it be better to have a signer whitelist instead or some > combination? E.g. you could whiteliste either by signer or > enclave signature. > I'm not sure, and also don't really think we need to commit to an answer right now. I do think that the eventual solution should be more flexible than just whitelisting the signers. In particular, it should be possible to make secure enclaves, open-source or otherwise, that are reproducibly buildable. This more or less requires that the signing private key not be a secret, which means that no one would want to whitelist the signing key. The enclave would be trusted, and would seal data, on the basis of its MRENCLAVE, and the policy, if any, would want to whitelist the MRENCLAVE or perhaps the whole SIGSTRUCT. But my overall point is that it should be possible to have a conherent policy that allows any enclave whatsoever to run but that still respects EXECMEM and such. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits 2019-08-04 22:20 ` Andy Lutomirski @ 2019-08-05 20:51 ` Jarkko Sakkinen 2019-08-05 21:30 ` Andy Lutomirski 0 siblings, 1 reply; 8+ messages in thread From: Jarkko Sakkinen @ 2019-08-05 20:51 UTC (permalink / raw) To: Andy Lutomirski Cc: Sean Christopherson, Schaufler, Casey, James Morris, linux-sgx, Dave Hansen, Cedric Xing, Jethro Beekman, Dr . Greg Wettstein, Stephen Smalley, LSM List On Sun, Aug 04, 2019 at 03:20:24PM -0700, Andy Lutomirski wrote: > On Thu, Aug 1, 2019 at 9:38 AM Jarkko Sakkinen > <jarkko.sakkinen@linux.intel.com> wrote: > > > > On Mon, Jul 15, 2019 at 03:29:23PM -0700, Andy Lutomirski wrote: > > > I would say it differently: regardless of exactly how /dev/sgx/enclave > > > is wired up under the hood, we want a way that a process can be > > > granted permission to usefully run enclaves without being granted > > > permission to execute whatever bytes of code it wants. Preferably > > > without requiring LSMs to maintain some form of enclave signature > > > whitelist. > > > > Would it be better to have a signer whitelist instead or some > > combination? E.g. you could whiteliste either by signer or > > enclave signature. > > > > I'm not sure, and also don't really think we need to commit to an > answer right now. I do think that the eventual solution should be > more flexible than just whitelisting the signers. In particular, it > should be possible to make secure enclaves, open-source or otherwise, > that are reproducibly buildable. This more or less requires that the > signing private key not be a secret, which means that no one would > want to whitelist the signing key. The enclave would be trusted, and > would seal data, on the basis of its MRENCLAVE, and the policy, if > any, would want to whitelist the MRENCLAVE or perhaps the whole > SIGSTRUCT. > > But my overall point is that it should be possible to have a conherent > policy that allows any enclave whatsoever to run but that still > respects EXECMEM and such. So could kernel embed a fixed signing key that would be made available through sysfs for signing? Already have one for my selftest. /Jarkko ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits 2019-08-05 20:51 ` Jarkko Sakkinen @ 2019-08-05 21:30 ` Andy Lutomirski 2019-08-07 18:51 ` Jarkko Sakkinen 0 siblings, 1 reply; 8+ messages in thread From: Andy Lutomirski @ 2019-08-05 21:30 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Andy Lutomirski, Sean Christopherson, Schaufler, Casey, James Morris, linux-sgx, Dave Hansen, Cedric Xing, Jethro Beekman, Dr . Greg Wettstein, Stephen Smalley, LSM List On Mon, Aug 5, 2019 at 1:51 PM Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote: > > On Sun, Aug 04, 2019 at 03:20:24PM -0700, Andy Lutomirski wrote: > > On Thu, Aug 1, 2019 at 9:38 AM Jarkko Sakkinen > > <jarkko.sakkinen@linux.intel.com> wrote: > > > > > > On Mon, Jul 15, 2019 at 03:29:23PM -0700, Andy Lutomirski wrote: > > > > I would say it differently: regardless of exactly how /dev/sgx/enclave > > > > is wired up under the hood, we want a way that a process can be > > > > granted permission to usefully run enclaves without being granted > > > > permission to execute whatever bytes of code it wants. Preferably > > > > without requiring LSMs to maintain some form of enclave signature > > > > whitelist. > > > > > > Would it be better to have a signer whitelist instead or some > > > combination? E.g. you could whiteliste either by signer or > > > enclave signature. > > > > > > > I'm not sure, and also don't really think we need to commit to an > > answer right now. I do think that the eventual solution should be > > more flexible than just whitelisting the signers. In particular, it > > should be possible to make secure enclaves, open-source or otherwise, > > that are reproducibly buildable. This more or less requires that the > > signing private key not be a secret, which means that no one would > > want to whitelist the signing key. The enclave would be trusted, and > > would seal data, on the basis of its MRENCLAVE, and the policy, if > > any, would want to whitelist the MRENCLAVE or perhaps the whole > > SIGSTRUCT. > > > > But my overall point is that it should be possible to have a conherent > > policy that allows any enclave whatsoever to run but that still > > respects EXECMEM and such. > > So could kernel embed a fixed signing key that would be made available > through sysfs for signing? Already have one for my selftest. > Do you mean a public and private key? I was imagining that someone would just create a key pair and publish it for the case of SGX programs that don't depend on MRSIGNER. There doesn't have to be just one. But I may be misunderstanding you. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits 2019-08-05 21:30 ` Andy Lutomirski @ 2019-08-07 18:51 ` Jarkko Sakkinen 0 siblings, 0 replies; 8+ messages in thread From: Jarkko Sakkinen @ 2019-08-07 18:51 UTC (permalink / raw) To: Andy Lutomirski Cc: Sean Christopherson, Schaufler, Casey, James Morris, linux-sgx, Dave Hansen, Cedric Xing, Jethro Beekman, Dr . Greg Wettstein, Stephen Smalley, LSM List On Mon, Aug 05, 2019 at 02:30:22PM -0700, Andy Lutomirski wrote: > On Mon, Aug 5, 2019 at 1:51 PM Jarkko Sakkinen > <jarkko.sakkinen@linux.intel.com> wrote: > > > > On Sun, Aug 04, 2019 at 03:20:24PM -0700, Andy Lutomirski wrote: > > > On Thu, Aug 1, 2019 at 9:38 AM Jarkko Sakkinen > > > <jarkko.sakkinen@linux.intel.com> wrote: > > > > > > > > On Mon, Jul 15, 2019 at 03:29:23PM -0700, Andy Lutomirski wrote: > > > > > I would say it differently: regardless of exactly how /dev/sgx/enclave > > > > > is wired up under the hood, we want a way that a process can be > > > > > granted permission to usefully run enclaves without being granted > > > > > permission to execute whatever bytes of code it wants. Preferably > > > > > without requiring LSMs to maintain some form of enclave signature > > > > > whitelist. > > > > > > > > Would it be better to have a signer whitelist instead or some > > > > combination? E.g. you could whiteliste either by signer or > > > > enclave signature. > > > > > > > > > > I'm not sure, and also don't really think we need to commit to an > > > answer right now. I do think that the eventual solution should be > > > more flexible than just whitelisting the signers. In particular, it > > > should be possible to make secure enclaves, open-source or otherwise, > > > that are reproducibly buildable. This more or less requires that the > > > signing private key not be a secret, which means that no one would > > > want to whitelist the signing key. The enclave would be trusted, and > > > would seal data, on the basis of its MRENCLAVE, and the policy, if > > > any, would want to whitelist the MRENCLAVE or perhaps the whole > > > SIGSTRUCT. > > > > > > But my overall point is that it should be possible to have a conherent > > > policy that allows any enclave whatsoever to run but that still > > > respects EXECMEM and such. > > > > So could kernel embed a fixed signing key that would be made available > > through sysfs for signing? Already have one for my selftest. > > > > Do you mean a public and private key? I was imagining that someone > would just create a key pair and publish it for the case of SGX > programs that don't depend on MRSIGNER. There doesn't have to be just > one. > > But I may be misunderstanding you. Aa, OK, got you. I actually misunderstood you. /Jarkko ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-08-07 18:51 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20190617222438.2080-1-sean.j.christopherson@intel.com> [not found] ` <20190617222438.2080-10-sean.j.christopherson@intel.com> [not found] ` <0c4f75a0ae2fdeee6db07f3a224918f321163d56.camel@linux.intel.com> [not found] ` <alpine.LRH.2.21.1906200702040.28119@namei.org> 2019-06-23 17:16 ` [RFC PATCH v3 09/12] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX Dr. Greg 2019-06-26 20:39 ` James Morris [not found] ` <20190617222438.2080-5-sean.j.christopherson@intel.com> [not found] ` <dc3d59c2783ea81d85d4d447bd1a4a2d5fe51421.camel@linux.intel.com> [not found] ` <20190619152018.GC1203@linux.intel.com> [not found] ` <20190620221702.GE20474@linux.intel.com> [not found] ` <20190707190809.GE19593@linux.intel.com> [not found] ` <1b7369a08e98dd08a4f8bb19b16479f12bee130f.camel@linux.intel.com> [not found] ` <20190708161932.GE20433@linux.intel.com> [not found] ` <20190709160634.3yupyabf5svnj4ds@linux.intel.com> [not found] ` <20190710172553.GE4348@linux.intel.com> 2019-07-15 22:29 ` [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits Andy Lutomirski 2019-08-01 16:38 ` Jarkko Sakkinen 2019-08-04 22:20 ` Andy Lutomirski 2019-08-05 20:51 ` Jarkko Sakkinen 2019-08-05 21:30 ` Andy Lutomirski 2019-08-07 18:51 ` Jarkko Sakkinen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).