Hi Kentaro,
I've just been looking at some of the VFS syscall routines, such as
notify_change(), with an eye to calling it from FS-Cache to grow a file. I
see that whilst notify_change() calls the inode-based LSM hooks (as drive
SELinux), it doesn't call the path-based LSM hooks (as drive other security
modules). It leaves that to the callers, such as do_sys_ftruncate().
I see that vfs_mkdir(), for example, is similar, in that vfs_mkdir() - which
I'm calling from FS-Cache - invokes the inode-based LSM hooks, but it bypasses
the path-based LSM hooks as those are called from sys_mkdir().
It would appear that path-based LSM hooks may well be being called from the
wrong places. They were added in:
commit be6d3e56a6b9b3a4ee44a0685e39e595073c6f0d
Author: Kentaro Takeda <[email protected]>
Date: Wed Dec 17 13:24:15 2008 +0900
introduce new LSM hooks where vfsmount is available.
Add new LSM hooks for path-based checks. Call them on directory-modifying
operations at the points where we still know the vfsmount involved.
Signed-off-by: Kentaro Takeda <[email protected]>
Signed-off-by: Tetsuo Handa <[email protected]>
Signed-off-by: Toshiharu Harada <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Using sys_mkdir() and suchlike directly from within the kernel would add a lot
of overhead as I'd have to generate a full pathname for each call, whereas
vfs_mkdir() or notify_change() allows me to start from an inode I already
have.
David
David,
thanks for your attention. :)
David Howells wrote:
> I've just been looking at some of the VFS syscall routines, such as
> notify_change(), with an eye to calling it from FS-Cache to grow a file. I
> see that whilst notify_change() calls the inode-based LSM hooks (as drive
> SELinux), it doesn't call the path-based LSM hooks (as drive other security
> modules). It leaves that to the callers, such as do_sys_ftruncate().
>
> I see that vfs_mkdir(), for example, is similar, in that vfs_mkdir() - which
> I'm calling from FS-Cache - invokes the inode-based LSM hooks, but it bypasses
> the path-based LSM hooks as those are called from sys_mkdir().
>
> It would appear that path-based LSM hooks may well be being called from the
> wrong places. They were added in:
>
> commit be6d3e56a6b9b3a4ee44a0685e39e595073c6f0d
> Author: Kentaro Takeda <[email protected]>
> Date: Wed Dec 17 13:24:15 2008 +0900
>
> introduce new LSM hooks where vfsmount is available.
>
> Add new LSM hooks for path-based checks. Call them on directory-modifying
> operations at the points where we still know the vfsmount involved.
>
> Signed-off-by: Kentaro Takeda <[email protected]>
> Signed-off-by: Tetsuo Handa <[email protected]>
> Signed-off-by: Toshiharu Harada <[email protected]>
> Signed-off-by: Al Viro <[email protected]>
Well, my understanding is that your question is related to two aspects of
the new LSM hooks: location and coverage.
(about location)
This patch introduced new LSM hooks outside vfs helper functions because
Al had adviced us that vfs helper functions should remain vfsmount-unaware.
(about coverage)
This patch is not intended to implement the equivalent of security_inode_*
hooks. This patch is for pathname-based MAC, especially for TOMOYO
in kernel 2.6.30.
> Using sys_mkdir() and suchlike directly from within the kernel would add a lot
> of overhead as I'd have to generate a full pathname for each call, whereas
> vfs_mkdir() or notify_change() allows me to start from an inode I already
> have.
Callers of sys_mkdir() and suchlike directly from within the kernel don't need
to generate a full pathname. Name based LSM will generate a full pathname from
dentry and vfsmount. There is no getname() nor path_walk() call.
Regards,
On Wed, Mar 25, 2009 at 04:14:13PM +0000, David Howells wrote:
>
> Hi Kentaro,
>
> I've just been looking at some of the VFS syscall routines, such as
> notify_change(), with an eye to calling it from FS-Cache to grow a file. I
> see that whilst notify_change() calls the inode-based LSM hooks (as drive
> SELinux), it doesn't call the path-based LSM hooks (as drive other security
> modules). It leaves that to the callers, such as do_sys_ftruncate().
>
> I see that vfs_mkdir(), for example, is similar, in that vfs_mkdir() - which
> I'm calling from FS-Cache - invokes the inode-based LSM hooks, but it bypasses
> the path-based LSM hooks as those are called from sys_mkdir().
>
> It would appear that path-based LSM hooks may well be being called from the
> wrong places. They were added in:
>
> commit be6d3e56a6b9b3a4ee44a0685e39e595073c6f0d
> Author: Kentaro Takeda <[email protected]>
> Date: Wed Dec 17 13:24:15 2008 +0900
>
> introduce new LSM hooks where vfsmount is available.
>
> Add new LSM hooks for path-based checks. Call them on directory-modifying
> operations at the points where we still know the vfsmount involved.
>
> Signed-off-by: Kentaro Takeda <[email protected]>
> Signed-off-by: Tetsuo Handa <[email protected]>
> Signed-off-by: Toshiharu Harada <[email protected]>
> Signed-off-by: Al Viro <[email protected]>
>
> Using sys_mkdir() and suchlike directly from within the kernel would add a lot
> of overhead as I'd have to generate a full pathname for each call, whereas
> vfs_mkdir() or notify_change() allows me to start from an inode I already
> have.
If you start from inode (or dentry, for that matter), you don't *have*
a pathname at all. The real question is, do you want these checks to
apply and if you do - which path do you want to use (esp. if you have
multiple namespaces)?
Al Viro <[email protected]> wrote:
> If you start from inode (or dentry, for that matter), you don't *have*
> a pathname at all.
When I'm starting from a dentry, I do have a vfsmount as well - it's just that
vfs_mkdir() or whatever doesn't currently take it (which is perhaps reasonable
as NFSD and eCryptFS might not have it available).
> The real question is, do you want these checks to apply and if you do -
> which path do you want to use (esp. if you have multiple namespaces)?
The path to be used is straightforward: I do, after all, have a vfsmount, and
that plus dentry is all that is required for security_path_*() - which seems
slightly odd since it takes no account of chroot(), but that's probably fine.
As to whether these checks should be applied... The SELinux ones need to be,
so I'd've thought the same would be true for TOMOYO.
Seems I might need to split such as sys_mkdirat() to separate the path lookup
from the security checks:-/
As I said, what I don't want to have to do is attempt to regenerate the full
pathname, especially if the pathname isn't accessible from within the current
process's chroot or namespace.
David
On Thu, Mar 26, 2009 at 04:14:26PM +0000, David Howells wrote:
> As I said, what I don't want to have to do is attempt to regenerate the full
> pathname, especially if the pathname isn't accessible from within the current
> process's chroot or namespace.
... and if it's not accessible from said process' namespace, pathname-based
checks are going to produce really bizarre results.
IOW, I'd say that such checks simply don't apply in case of fscache.