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@xxxxxxxxxxxxxxxx/
> 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.
>
> Anyway, we also need to have a call to landlock_release_inodes() in
> generic_shutdown_super(), which does not fit the LSM framework, and I
> think it is not an issue. Landlock handling of inodes is quite similar
> to fsnotify.
