On Tue, Jul 02, 2019 at 08:44:40AM -0700, Casey Schaufler wrote: Good morning, I hope this note finds the week going well for everyone. > On 7/2/2019 12:42 AM, Xing, Cedric wrote: > > ... > > Guess this discussion will never end if we don't get into > > code. Guess it'd be more productive to talk over phone then come back > > to this thread with a conclusion. Will that be ok with you? > I don't think that a phone call is going to help. Talking code > issues tends to muddle them in my brain. If you can give me a few > days I will propose a rough version of how I think your code should > be integrated into the LSM environment. I'm spending more time > trying (unsuccessfully :( ) to discribe the issues in English than > it will probably take in C. While Casey is off writing his rosetta stone, let me suggest that the most important thing we need to do is to take a little time, step back and look at the big picture with respect to what we are trying to accomplish and if we are going about it in a way that makes any sense from an engineering perspective. This conversation shouldn't be about SGX, it should be about the best way for the kernel/LSM to discipline a Trusted Execution Environment (TEE). As I have noted previously, a TEE is a 'blackbox' that, by design, is intended to allow execution of code and processing of data in a manner that is resistant to manipulation or inspection by untrusted userspace, the kernel and/or the hardware itself. Given that fact, if we are to be intellectually honest, we need to ask ourselves how effective we believe we can be in controlling any TEE with kernel based mechanisms. This is particularly the case if the author of any code running in the TEE has adversarial intent. Here is the list of controls that we believe an LSM can, effectively, implement against a TEE: 1.) Code provenance and origin. 2.) Cryptographic verification of dynamically executable content. 2.) The ability of a TEE to implement anonymous executable content. If people are in agreement with this concept, it is difficult to understand why we should be implementing complex state machines and the like, whether it is in the driver or the LSM. Security code has to be measured with a metric of effectiveness, otherwise we are engaging in security theater. I believe that if we were using this lens, we would already have a mainline SGX driver, since we seem to have most of the needed LSM infrastructure and any additional functionality would be a straight forward implementation. Most importantly, the infrastructure would not be SGX specific, which would seem to be a desirable political concept. If we are not willing to engage in this discussion we are going to end up with a quasi-technology specific solution that isn't implementing any relevant security guarantees. FWIW, we wouldn't even be having this, now lengthy discussion, if I wouldn't have aggressively advocated, starting last November, that an SGX driver needed some form of execution control if there was a desire for the technology to not pose a security risk to the platform. So humor me a little bit.... :-) Best wishes for a productive remainder of the 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: greg@xxxxxxxxxxxx ------------------------------------------------------------------------------ "... remember that innovation is saying 'no' to 1000 things."
