Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Threat model for EdgeX Secret Store #1
Discussion question: Should system management agent be modified to pass bootstrapping secrets to services or should system management and security be entirely separate?
Answer; No. They should be separate functionality. Current design does not hand-off from a native executor to SMA in the same way that a Linux kernel hands off to init.
Discussion question: Should secret management be unsupported when using Linux OS executor or should Linux OS executor require UID/GID separation of users?
Answer: Yes. The two supported executors in the reference implementation are docker and snap. Implementations based on standard processes will be missing important threat mitigations.
tonyespy left a comment
Pretty thorough assessment Bryon!
This is a first pass at a review, but I have to say didn't expect such a comprehensive and lengthy assessment. I also mention somewhere in my comments that at first what I thought this document was an assessment of the current state of security, but in fact this a full-blown detailed design and plan on how to mitigate the existing vulnerabilities over the course of multiple releases.
It's not clear to me how much of this is actually being proposed for Edinburgh vs. the recent proposal put forth by Jim & Ting-yu. Frankly there's enough work detailed here for a couple of a releases, and I think it will be a challenge to identify how much of this is actually do-able in the Fuji time-frame.
Finally, while some folks will absolutely want the most secure implementation possible, there will be deployments of EdgeX where the OS and/or specialized hardware provide a greater level of protection than the base-line assumptions you've made. There's no mention of any choice of how much is turned on by default, or mandatory vs. optional.
My understanding is Ting-yu will finish up Edinburgh, and then Jim and I will start working on some version of this for Fuji.
The SMA executor could be something other than a docker-compose or Linux OS executor. Those are just provided by ref impl, but others can and probably will exist.
I echo a lot of the sentiments...
OK. Won't require it then.
The feedback, that I have confirmed in in systems-management WG, is that the two executors are docker and snap. Someone running a Linux OS executor would have to understand that the reference mitigations may be insufficient.
Here are my thoughts: How about if the
I have since learned that these types of protections (mandatory access control) are implemented by the snap executor.
The threat model should be aligned with the intended use case of EdgeX. If a closed network were the assumption, that would mean that the secret engine would have be be replaced by someone who intended to use EdgeX on a non-closed network.
In a similar vein, the sentiment expressed thus far is that a docker or snap executor should be assumed; someone implementing on less than that would need to implement equivalent protections on their own as part of their security design.
Yes. The action plan focuses on a software-first implementation. However, I have not been clear that hardware is an option. Moreover, the sentiment that a hardware implementation should be out-of-tree. Correct me if I am wrong.
@jpwhitemn some comments/questions on your response:
If this is the case then it seems like the token-issuing service will need to somehow integrate into that orchestration service. I think that this requires close design work between the SMA and the token-issuing service proposed here, such that the following situations are covered:
With the following capabilities handled correctly:
I keep hearing reference to this Linux OS executor? Is this actually being worked on or did you mean to say the snap executor?
Before we get to defining an abstraction layer, we have to define what's in scope and out of scope here. I think that utilizing a TPM or TEE is very much in-scope and so an abstraction layer may be needed.
Also note that while I agree that in general the system needs to accommodate running without hardware security and without security in general as it does today, however, we shouldn't try to target running securely in situations where the deployment system doesn't support any of the features we could take advantage of, such as AppArmor, SELinux, kernel namespaces in the case of containers, etc. We should evaluate different software and hardware confinement mechanisms and choose a set of features that we can rely on that is wide enough to allow for many different deployment scenarios but not every deployment scenario. Trying to securely support every possible combination will be too much work, and as I pointed out above, we shouldn't ignore the work that has already been done to make this easy for us in the form of linux security modules, etc.
I think that we could try to be generic as possible with a reference implementation, utilizing something like https://github.com/Microsoft/openenclave in order to write the most generically useful code possible for a reference implementation or abstraction layer.
Can you explain more or give an example? Why would a device service be incapable of working within the prescribed security?
To me at least, I think it's too early to be putting these steps into concrete plans. We still are discussing the scope of a secret store and before we can decide on steps to implement, we have to finalize the design and scope of it.
I can't say I agree with that until we hear more details on what exactly this Linux OS executor is... If the Linux OS executor is simply running processes without any software or hardware confinement then I agree that they need to implement their own mitigations or run EdgeX within their own security confinement systems.
Well if we are designing around a TEE, wouldn't the TEE have the passphrase inside it and not share it outside the TEE? This could mean for example that vault-worker runs inside the TEE or that Vault runs inside the TEE and the token-issuing service or vault-worker talks to Vault inside the TEE.
To be clear, the snap implements both MAC and LSM based software confinement. MAC is implemented such that only root user can access sensitive files in the snap's config (such as the TLS keys for kong/vault), and only root can write to particular configuration files in the snap's config.
I agree with this sentiment. I also think that the current proposal can still work within a closed network like a factory? I don't see how anywhere in this design we depend upon access to the open internet.
I think you have been clear that hardware backed security is an option, but some level of software security will be mandatory to fit into this design.
There are several possible ways to accommodate a TEE: