linux-kernel - Re: [GIT PULL] selinux/selinux-pr-20250323

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]

Message-ID: <CAEjxPJ4fzoONpiy3z8QOZ55w35=WfWQ+hiTg24LMEHPpnaC87Q@mail.gmail.com>
Date: Thu, 27 Mar 2025 15:16:35 -0400
From: Stephen Smalley <stephen.smalley.work@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jeffrey Vander Stoep <jeffv@...gle.com>, Thiébaud Weksteen <tweek@...gle.com>, 
	Paul Moore <paul@...l-moore.com>, "Cameron K. Williams" <ckwilliams.work@...il.com>, 
	"Kipp N. Davis" <kippndavis.work@....com>, selinux@...r.kernel.org, 
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Nick Kralevich <nnk@...gle.com>, Kees Cook <kees@...nel.org>
Subject: Re: [GIT PULL] selinux/selinux-pr-20250323

On Thu, Mar 27, 2025 at 3:03 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Thu, 27 Mar 2025 at 11:15, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > The best fix would be to be able to cache the "this doesn't have any
> > extra security rules outside of the regular POSIX ones" and avoid
> > calling the hook entirely. That's what we've done for the ACL path,
> > and that has turned ACL costs into almost a non-issue.
>
> .. just to follow up on that, because I tried to look into it, but
> didn't know the lsm and selinux code well enough to actually make much
> progress, so if somebody who does is really willing to take a deeper
> look, please pester me for details.

Would be interested in those details.

> But the big high-level case for pathname lookup tends to be the calls
> we have to do not just for the final inode, but the "every single
> component" cases.
>
> Which is a much *simpler* and more targeted security check than the
> "any random permissions". It's the "can I use this directory for
> lookups", and if we had an inode flag that said "this inode has no
> security policies that change the lookup rules", just that single big
> would likely be a *huge* improvement.
>
> Because then you don't need to try to optimize the security check
> itself, because instead the VFS layer can optimize it all by not
> calling into the security layer at all.
>
> And from a "this is called too much" standpoint, the "every path
> component" cases tend to outnumber the "final file open" case by
> something like 5-to-1 (handwavy, but not entirely made up).
>
> I think the main case is
>
>    link_path_walk -> may_lookup -> security_inode_permission
>
> where the special case is that may_lookup() only sets MAY_EXEC and
> MAY_NOT_BLOCK (for the RCU lookup case, which is what matters).
>
> So if inode_permission() (in fs/namei.c) could avoid calling
> security_inode_permission() because the inode has some flag that says
> "none of the security models disallow MAY_EXEC for this directory
> walk", I really think that would help.
>
> I think trying to optimize the AVC hash table lookup further or
> something like that is a dead end. The cost is "many many many calls",
> and each individual call is fairly cheap on its own, but they all walk
> different hash chains, and it all adds up to "lots of cost".
>
> Hmm?

Where could/would we cache that information so that it was accessible
directly by the VFS layer?