> From: linux-sgx-owner@xxxxxxxxxxxxxxx [mailto:linux-sgx- > owner@xxxxxxxxxxxxxxx] On Behalf Of Stephen Smalley > Sent: Friday, June 28, 2019 9:17 AM > > FWIW, adding new permissions only requires updating policy configuration, > not userspace code/tools. But in any event, we can reuse the execute- > related permissions if it makes sense but still consider introducing > additional, new permissions, possibly in a separate "enclave" security > class, if we want explicit control over enclave loading, e.g. > ENCLAVE__LOAD, ENCLAVE__INIT, etc. I'm not so familiar with SELinux tools so my apology in advance if I end up mixing up things. I'm not only talking about the new permissions, but also how to apply them to enclave files. Intel SGX SDK packages enclaves as .so files, and I guess that's the most straight forward way that most others would do. So if different permissions are defined, then user mode tools would have to distinguish enclaves from regular .so files in order to grant them different permissions. Would that be something extra to existing tools? > > One residual concern I have with the reuse of FILE__EXECUTE is using it > for the sigstruct file as the fallback case. If the sigstruct is always > part of the same file as the code, then it probably doesn't matter. But > otherwise, it is somewhat odd to have to allow the host process to > execute from the sigstruct file if it is only data (the signature). I agree with you. But do you think it a practical problem today? As far as I know, no one is deploying sigstructs in dedicated files. I'm just trying to touch as few things as possible until there's definitely a need to do so.
