TOMOYO is one of AppArmor's friends, and I am the guy who proposed to pass
a reference to vfsmount via task_struct as if that reference is passed via stack memory.
I'm not asking to pass the vfsmount parameter to individual filesystem's "vfs functions".
I'm asking to pass the vfsmount parameter to the "vfs *helper* functions".
So, filesytem will not care where it is mounted
even if the vfsmount is passed to "vfs *helper* functions".
The vfs helper functions are designed to aggregate common checks (permission checks,
inode_operations->foo existence checks etc.) to avoid scattering same code everywhere
in the kernel, didn't they?
At least, calls to vfs helper functions from userland code
_do_ have the vfsmount available because they are called immediately after the name resolution.
Calls to vfs helper functions from kernel code does not always have the vfsmount available,
but that's beyond what the LSM can do.
We must trust kernel code, because kernel code can bypass the LSM check
if the kernel code is malicious enough to directly call "vfs functions" instead of
calling "vfs helper functions".
(Or, more simply, kernel code can rewrite the call to the LSM check to no-op
like funny workaround for vmsplice's vulnerability).
I think attempt to receive the vfsmount from kernel code won't help guaranteeing that
LSM's security checks are always performed.
Routes to access "vfs functions" from kernel code is undeterminable.
In other words, LSM can't guarantee that LSM's security checks are always performed
against the kernel code regardless of the security model.
But, at least, LSM can guarantee that LSM's security checks are always performed
against the userland code regardless of the security model.
Routes to access "vfs functions" from userland code is determinable.
So, making the vfsmount available to LSM make sense.
I don't care if the vfsmount is unavailable when the vfs helper function call was
issued from kernel code.
--
