I am currently upgrading the source code of a Linux LSM (kernel 4.3.5) to the be compatible with the newest version of the Linux kernel.
I have successfully updated the code, so the GCC compiler successfully compiles, however the kernel will not boot.
Up until this point, I have not used the LSM MAJOR flag or the EXCLUSIVE flag in the definition of the module, however when booting into the non working kernel, SMACK and SELinux (depending on which one is selected as the major) error out and mention kmem_cache_free in the trace. My understanding is that due to this my LSM must be implemented as legacy major and exclusive. This is because SMACK or Selinux aren't playing well with my LSM, just like they don't with each other? (As a note SMACK and Selinux both use the exclusive and legacy major flags)
The LSM I am developing uses xattrs to save rules to an inode, and the LSM provides mediation to the inode based on the rules.
In all of the documentation I have read, security blobs keep popping up, now my understanding is that they are kernel data structures, and if I am only accessing inodes, I shouldn't need to implement one?
The LSM does use a kernel cache with kmem_cache_create(), which SELinux also did in their 4.3.5 kernel version, is this a security blob?
To recap:
What is the use case for a major or minor LSM in this context?
Does a security blob replace the use of
kmem_cache_create()?