linux-kernel - Re: [PATCH bpf-next 2/2] selftests/bpf: Extend test fs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <41CA4718-EE8E-499B-AC3C-E22C311035E7@fb.com>
Date: Wed, 30 Oct 2024 20:44:26 +0000
From: Song Liu <songliubraving@...a.com>
To: Christoph Hellwig <hch@...radead.org>
CC: Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        Song Liu
	<songliubraving@...a.com>, Song Liu <song@...nel.org>,
        bpf
	<bpf@...r.kernel.org>,
        Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML
	<linux-kernel@...r.kernel.org>,
        Kernel Team <kernel-team@...a.com>,
        Andrii
 Nakryiko <andrii@...nel.org>,
        Eduard Zingerman <eddyz87@...il.com>,
        Alexei
 Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin
 KaFai Lau <martin.lau@...ux.dev>,
        Al Viro <viro@...iv.linux.org.uk>, KP Singh
	<kpsingh@...nel.org>,
        Matt Bobrowski <mattbobrowski@...gle.com>
Subject: Re: [PATCH bpf-next 2/2] selftests/bpf: Extend test fs_kfuncs to
 cover security.bpf xattr names

Hi Christoph, 

> On Oct 22, 2024, at 11:45 PM, Christoph Hellwig <hch@...radead.org> wrote:
> 
> On Mon, Oct 21, 2024 at 03:24:30PM +0200, Christian Brauner wrote:
>> On Thu, Oct 17, 2024 at 08:03:51AM -0700, Christoph Hellwig wrote:
>>> On Wed, Oct 16, 2024 at 04:51:37PM +0200, Christian Brauner wrote:
>>>>> 
>>>>> I think that getting user.* xattrs from bpf hooks can still be useful for
>>>>> introspection and other tasks so I'm not convinced we should revert that
>>>>> functionality but maybe it is too easy to misuse? I'm not really decided.
>>>> 
>>>> Reading user.* xattr is fine. If an LSM decides to built a security
>>>> model around it then imho that's their business and since that happens
>>>> in out-of-tree LSM programs: shrug.
>>> 
>>> By that argument user.kfuncs is even more useless as just being able
>>> to read all xattrs should be just as fine.
>> 
>> bpf shouldn't read security.* of another LSM or a host of other examples...
> 
> Sorry if I was unclear, but this was all about user.*.

Given bpf kfuncs can read user.* xattrs for almost a year now, I think we 
cannot simply revert it. We already have some users using it. 

Instead, we can work on a plan to deprecated it. How about we add a 
WARN_ON_ONCE as part of this patchset, and then remove user.* support 
after some time?

Thanks,
Song