On Tue, Jul 2, 2024 at 7:50 AM Andi Kleen <ak@xxxxxxxxxxxxxxx> 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
