lkml.org 
[lkml]   [2008]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: r-o bind in nfsd
From
Date
Hello.

> As for the apparmor and friends... I'm far past the point of trying to
> give them feedback, seeing how any such feedback is ignored, if not worse
> (the ugliness of some of the suggested kludges is bloody astonishing - e.g.
> some guy proposed to stuff a reference to vfsmount into task_struct, etc.)
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.

> > Because filesystem shouldn't _care_ where it is mounted. Anything
> > vfsmount-dependent belongs to upper layers. The same goes for passing
> > nameidata to fs methods, BTW - again, ->follow_link() is an obvious
> > legitimate exception.
>
> Nobody wants to send vfsmounts to the filesystem. But vfs_...() are
> still part of the "upper layer", not the filesystem, so I'm not
> convinced yet. For example:
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?

> Assuming of course, that all valid users _do_ have the vfsmount
> available, which I think is true. If you have a counterexample,
> please let us know.
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.


\
 
 \ /
  Last update: 2008-03-22 03:23    [W:0.172 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site