On 14/05/2020 17:58, Casey Schaufler wrote:
On 5/14/2020 3:39 AM, Mickaël Salaün wrote:
On 14/05/2020 05:37, James Morris wrote:
On Mon, 11 May 2020, Mickaël Salaün wrote:
diff --git a/include/linux/fs.h b/include/linux/fs.h index 45cc10cdf6dd..2276642f8e05 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1517,6 +1517,11 @@ struct super_block { /* Pending fsnotify inode refs */ atomic_long_t s_fsnotify_inode_refs; +#ifdef CONFIG_SECURITY_LANDLOCK
- /* References to Landlock underlying objects */
- atomic_long_t s_landlock_inode_refs;
+#endif
This needs to be converted to the LSM API via superblock blob stacking.
See Casey's old patch: https://lore.kernel.org/linux-security-module/20190829232935.7099-2-casey@sc...
s_landlock_inode_refs is quite similar to s_fsnotify_inode_refs, but I can do it once the superblock security blob patch is upstream. Is it a blocker for now? What is the current status of lbs_superblock?
As no currently stackable modules conflict over the superblock (SELinux and Smack are the existing users) there has been no need to move its management into the infrastructure. The active push for stacking does not (yet) include everything needed for SELinux+Smack. It includes what is needed for SELinux+AppArmor and Smack+AppArmor. That does not include the superblock blob.
You can include a patch in the landlock set that provides infrastructure management of the superblock blob. Feel free to glean it from my proposal.
OK, I'll add it to the next series.