linux-kernel - Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput -33.7% regression

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: <CAGudoHHkxyCkLZ4xwQ9ho5uy0TQ4K1ENJMmSYDZkaZw6YF4VEA@mail.gmail.com>
Date: Wed, 3 Jul 2024 16:11:25 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: Christian Brauner <brauner@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev, lkp@...el.com, 
	Linux Memory Management List <linux-mm@...ck.org>, linux-kernel@...r.kernel.org, ying.huang@...el.com, 
	feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput
 -33.7% regression

On Wed, Jul 3, 2024 at 4:09 PM Christian Brauner <brauner@...nel.org> wrote:
>
> > As a side note this is where I should also note the *current* LSM hooks
> > are racy as is.  Suppose you can stat a particular file now, but a chown
> > to 1234 means you can't. Then your stat call can race against chown +
> > other ops. You can end up in a state where LSMs gave a green light and
> > only then the state changed to one you are not allowed to look at. This
>
> Fwiw, we've discussed this before. And my opinion is that we should
> absolute not care about this. I have no interest in complicating path
> lookup or any codepath to make these hooks less racy. This raciness they
> have to deal with. This is not a comment on your patch but just that the
> raciness of security hooks is not a problem we should care to solve
> imho. If we go down that road we'll all slowly go insane trying to give
> state change guarantees to layers that hook into the VFS in really odd
> locations.

Well I noted I have no interest in working on it anyway, so... I think
we are good here on this front :)

-- 
Mateusz Guzik <mjguzik gmail.com>