On 6/28/2019 6:37 PM, Stephen Smalley wrote: > On Fri, Jun 28, 2019 at 1:22 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >> On 6/27/2019 5:47 PM, Xing, Cedric wrote: >>>> From: Casey Schaufler [mailto:casey@xxxxxxxxxxxxxxxx] >>>> Sent: Thursday, June 27, 2019 4:37 PM >>>>>> This code should not be mixed in with the LSM infrastructure. >>>>>> It should all be contained in its own module, under security/enclave. >>>>> lsm_ema is *intended* to be part of the LSM infrastructure. >>>> That's not going to fly, not for a minute. >>> Why not, if there's a need for it? >>> >>> And what's the concern here if it becomes part of the LSM infrastructure. >> The LSM infrastructure provides a framework for hooks >> and allocation of blobs. That's it. It's a layer for >> connecting system features like VFS, IPC and the IP stack >> to the security modules. It does not implement any policy >> of it's own. We are not going to implement SGX or any other >> mechanism within the LSM infrastructure. > I don't think you understand the purpose of this code. It isn't > implementing SGX, nor is it needed by SGX. > It is providing shared infrastructure for security modules, similar to > lsm_audit.c, so that security modules can enforce W^X or similar > memory protection guarantees for SGX enclave memory, which has unique > properties that render the existing mmap and mprotect hooks > insufficient. They can certainly implement it only for SELinux, but > then any other security module that wants to provide such guarantees > will have to replicate that code. I am not objecting to the purpose of the code. I *am* objecting to calling it part of the LSM infrastructure. It needs to be it's own thing, off somewhere else. It must not use the lsm_ prefix. That's namespace pollution. The code must not be embedded in the LSM infrastructure code, that breaks with how everything else works. ... and the notion that you allocate data for one blob that gets freed relative to another breaks the data management model.
