linux-kernel - Re: [PATCH 1/2] bpf: Add BPF_MAP_TYPE_CRED

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: <CAEXv5_jCXKm4L6tJy5X6kjoLpoPqkbRLuhGuEMYNwoW=EYYtsw@mail.gmail.com>
Date: Tue, 16 Sep 2025 12:36:01 -0400
From: David Windsor <dwindsor@...il.com>
To: Song Liu <song@...nel.org>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>, bpf <bpf@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Eduard <eddyz87@...il.com>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>
Subject: Re: [PATCH 1/2] bpf: Add BPF_MAP_TYPE_CRED_STORAGE map type and kfuncs

On Tue, Sep 16, 2025 at 12:16 PM Song Liu <song@...nel.org> wrote:
>
> On Tue, Sep 16, 2025 at 8:25 AM David Windsor <dwindsor@...il.com> wrote:
> [...]
> > >
> > > makes sense thanks
> > >
> >
> > Hi,
> >
> > Thinking about this more, hashmaps are still problematic for this case.
> >
> > Meaning, placing a hook on security_cred_free alone for garbage
> > collection / end-of-life processing isn't enough - we still have to
> > deal with prepare/commit_creds. This flow works by having
> > prepare_creds clone an existing cred object, then commit_creds works
> > by swapping old creds with new one atomically, then later freeing the
> > original cred. If we are not very careful there will be a period of
> > time during which both cred objects could be valid, and I think this
> > is worth the feature alone.
>
> With cred local storage, we still need to deal with prepare/commit creds,
> right? cred local storage only makes sure the storage is allocated and
> freed. The BPF LSM programs still need to initiate the data properly
> based on the policy. IOW, whether we have cred local storage or not,
> it is necessary to handle all the paths that alloc/free the cred. Did I miss
> something here?
>

Yes each LSM will have to do whatever it feels it should. Some will
initialize their blob's data with one type of data, some another,
depends on the LSM's use case. We're just here to provide the storage
- bpf cannot use the "classic" LSM storage blob.

I was referring to the fact that if we use a hashmap to track state on
a per-cred basis there may be a period of time when it could be come
stale during the state change from commit -> prepare_creds.

Thanks,
David

> Thanks,
> Song