Re: [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Tue, Jul 2, 2024 at 7:50 AM Andi Kleen <ak@linux.intel.com> wrote:
>
> > 1) non-executable file-backed VMA still has build ID associated with
> > it. Note, build ID is extracted from the backing file's content, not
> > from VMA itself. The part of ELF file that contains build ID isn't
> > necessarily mmap()'ed at all
>
> That's true, but there should be at least one executable mapping
> for any useful ELF file.
>
> Basically such a check guarantee that you cannot tell anything
> about a non x mapping not related to ELF.
>

Ok, I can add this check. If you know off the top of your head how to
do that for struct address_space, I'd appreciate the pointer. Quick
glance didn't show anything useful in linux/fs.h, but I'll dig deeper
a bit later.

> >
> > 2) What sort of exploitation are we talking about here? it's not
> > enough for backing file to have correct 4 starting bytes (0x7f"ELF"),
> > we still have to find correct PT_NOTE segment, and .note.gnu.build-id
> > section within it, that has correct type (3) and key name "GNU".
>
> There's a timing side channel, you can tell where the checks
> stop. I don't think it's a big problem, but it's still better to avoid
> such leaks in the first place as much as possible.
>
> >
> > I'm trying to understand what we are protecting against here.
> > Especially that opening /proc/<pid>/maps already requires
> > PTRACE_MODE_READ permissions anyways (or pid should be self).
>
> While that's true for the standard security permission model there might
> be non standard ones where the relationship is more complicated.
>

Presumably non-standard ones will have more and custom security checks
(LSM, seccomp, etc) involved. Basically, I acknowledge your point, but
I'm not sure it changes anything about adding this API.

> -Andi