On Fri, Feb 21, 2020 at 7:16 PM Dr. Greg <greg@xxxxxxxxxxxx> wrote: > > On Tue, Feb 18, 2020 at 07:00:23AM -0800, Andy Lutomirski wrote: > > > > On Feb 18, 2020, at 2:43 AM, Dr. Greg Wettstein <gw@xxxxxxxxxxxx> wrote: > > No, this isn't the fundamental issue, because DAC/MAC is just as > > relevant to systems with SGX and SGX2. I'm sure that there will > > be systems that work with SGX and with everything running as root > > (or even SGX on a kernel without access control at all), but these > > will be a minority. Even if you have absolutely perfect protection > > of sensitive data, you sacrifice any sort of defense in depth > > against an attacker DoSing you in any number of amazing ways. Or, > > for that matter, leaking keys derived from the provisioning key. > > I should have been more precise, my apologies. > > When I was suggesting that DAC/MAC controls were not relevant, I was > referring to their relevance with respect to protecting the platform > from running code that does not have defined provenance or origin. Windows systems quite regularly get owned by code with "defined provenance or origin" in the sense that it was signed by a valid Authenticode certificate. :) > I'm certainly not argueing against defense in depth or the merits of > DAC/MAC controls. I'm simply stating that they are irrelevant, with > respect to the concerns that you raised about code provenance and > origin, on flexible launch control platforms that support SGX2 and > EDMM. Platforms that by and large will be the primary target for this > driver. I have a little FLC platform on my desk. What I don't have is an FLC platform with anything resembling a policy that helps here at all. > I only bring up the issue in the interests of intellectual honesty and > the fact that I'm sure our exchanges will go down in the annals of > security history as being as important as the Lincoln/Douglas debates. That would be amazing! > > It is one of my jobs to follow the security literature closely. > Everyone who does so can easily envision a future abstract reading > something like the following: > > "Using an unmodified and stock DIST_OS kernel we were able to > demonstrate the download and execution of malicious code into an > enclave that bypasses all security controls in the Linux operating > system allowing us to recover XXXX information from the platform with > subsequent exfiltration of the information from the platform without > detection." > Alas, the significance of this seems to depend on what XXXX is. If XXXX is a detail of the specific machine (a derived provisioning key, a launch token, etc.), then the paper won't be terribly interesting. As root (or someone who can escalate to root or better) on a given system, I can extract *tons* of identifying details of the platform. If XXXX is a secret created by the user (a sealing key, something sealed by SGX, a private key or secret that allows one to pretend to be an enclave with MRSIGNER=YYY, etc), then launch control and DAC are essentially irrelevant to the discussion. What actually happened is that some code signed by YYY screwed up. And this is because launch control is not part of the SGX root of trust, nor is launch control even a necessary part of the SGX security model. SGX with launch control deleted entirely would be just as useful, if potentially a bit more dangerous in terms of being able to make malware hard to analyze. > > (Don't forget that, no matter how carefully your system might lock > > down the SGXPUBKEYHASH MSRs and control the associated keys, that > > lockdown is being done by non-enclave *software*, and a bad guy who > > gets root is quite likely to be able to unlock the registers by > > upgrading their root access to control the firmware. Or get a launch > > token that can't be revoked because SGX doesn't have a token > > expiration mechanism.) > > Dispassionate observers would note that you make the case for locked > launch control registers.... :-) > > At an SGX engineering meeting in Israel last summer, we made the case > for the fact that locked vs. unlocked platforms should be a BIOS > configurable option. With an additional option that specifying locked > also allows specification of what the identity modulus signature > should be. That would seem to be the best of all worlds, we will see > what happens. > > One of the pushbacks we received, is that SGX is supposed to be immune > from firmware manipulation, which our suggested approach would open > the door for, which we noted was irrelevant given the trajectory that > the Linux kernel driver is on, ie. no cryptographic controls over code > origin and provenance. I don't believe I have ever said that Linux shouldn't support cryptographic verification of SGX code provenance or that Linux shouldn't eventually support locked launch control MSRs. What I've said is that the initial upstream version of the driver doesn't need this, and that adding support for locked MSRs is tricky and needs some design work. FWIW, I didn't expect upstreaming to take anywhere near this long. > > Just to provide a frame of reference, our interest in SGX is with > respect to its guarantee of integrity of execution, for the purposes > of verifying that the kernel could not have executed code that was > outside a desired behavioral definition for the platform. SGX cannot and will never prevent the kernel from executing normal CPL0 code of any sort. I'm not really sure what you're getting at here. If you have magically trustworthy firmware and locked launch control registers, you can prevent the kernel from executing unapproved *enclave* code. It's not entirely clear to me why you consider unapproved enclave code to be worse than any other sort of unapproved code.
