linux-kernel - Re: Are path-based LSM hooks called from the wrong places?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Mar 2009 16:14:26 +0000
From:	David Howells <dhowells@...hat.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	dhowells@...hat.com, Kentaro Takeda <takedakn@...data.co.jp>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	Toshiharu Harada <haradats@...data.co.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: Are path-based LSM hooks called from the wrong places?

Al Viro <viro@...IV.linux.org.uk> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/