On 7/7/2019 6:30 AM, Dr. Greg wrote: > On Wed, Jul 03, 2019 at 08:32:10AM -0700, Casey Schaufler wrote: > > Good morning, I hope the weekend has been enjoyable 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, >> I'd hardly call it that. More of an effort to round the corners on >> the square peg. And Cedric has some ideas on how to approach that. > Should we infer from this comment that, of the two competing > strategies, Cedric's is the favored architecture? With Cedric's latest patches I'd say there's only one strategy. There's still some refinement to do, but we're getting there. >>> 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. >> Generality introduced in the absence of multiple instances >> often results in unnecessary complexity, unused interfaces >> and feature compromise. Guessing what other TEE systems might >> do, and constraining SGX to those models (or the other way around) >> is a well established road to ruin. The LSM infrastructure is >> a fine example. For the first ten years the "general" mechanism >> had a single user. I'd say to hold off on the general until there >> is more experience with the specific. It's easier to construct >> a general mechanism around things that work than to fit things >> that need to work into some preconceived notion of generality. > All well taken points from an implementation perspective, but they > elide the point I was trying to make. Which is the fact that without > any semblance of a discussion regarding the requirements needed to > implement a security architecture around the concept of a TEE, this > entire process, despite Cedric's well intentioned efforts, amounts to > pounding a square solution into the round hole of a security problem. Lead with code. I love a good requirements document, but one of the few places where I agree with the agile folks is that working code speaks loudly. > Which, as I noted in my e-mail, is tantamount to security theater. Not buying that. Not rejecting it, either. Without code to judge it's kind of hard to say. > Everyone wants to see this driver upstream. If we would have had a > reasoned discussion regarding what it means to implement proper > controls around a TEE, when we started to bring these issues forward > last November, we could have possibly been on the road to having a > driver with reasoned security controls and one that actually delivers > the security guarantees the hardware was designed to deliver. > > Best wishes for a productive week to everyone. > > Dr. Greg > > As always, > Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. > 4206 N. 19th Ave. Specializing in information infra-structure > Fargo, ND 58102 development. > PH: 701-281-1686 EMAIL: greg@xxxxxxxxxxxx > ------------------------------------------------------------------------------ > "Any intelligent fool can make things bigger and more complex... It > takes a touch of genius - and a lot of courage to move in the opposite > direction." > -- Albert Einstein
