This is mostly a follow-up of #25607 (debuginfod-client: paranoid federation mode) and #27758 (security idea: DEBUGINFOD_VERIFY mode) as I was looking at it again, but through a different approach: the downloaded files should be verified from something within the debugged binary that has been signed by $distro, so as not to trust a random binary downloaded from a random server (as pointed out in the federation mode bz), even if it's just for debuginfo parsing, as that code has had bugs. As things stand, fedora/debian still ship a .gnu_debuglink section whch contains a crc32 of the binary that can be verified: ``` $ file /lib64/libc.so.6 /lib64/libc.so.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=75fb4e8e3b20efcec877a571581917c4494a427e, for GNU/Linux 3.2.0, not stripped $ cd $HOME/.cache/debuginfod_client/75fb4e8e3b20efcec877a571581917c4494a427e $ objdump -s -j .gnu_debuglink /lib64/libc.so.6 /lib64/libc.so.6: file format elf64-x86-64 Contents of section .gnu_debuglink: 0000 6c696263 2e736f2e 362d322e 33382d36 libc.so.6-2.38-6 0010 2e666333 392e7838 365f3634 2e646562 .fc39.x86_64.deb 0020 75670000 21402d66 ug..!@-f $ cksfv debuginfo ; Generated by cksfv v1.3.15 on 2023-10-18 at 03:47.00 ; Project web site: https://gitlab.com/heikkiorsila/cksfv ; ; 9994312 09:00.00 2023-10-03 debuginfo debuginfo 662D4021 ``` -> 662d4021 matches 21402d66 Unfortunately a mere crc32 has no cryptography value, so this bz isn't so much about checking with .gnu_debuglink, than a much bigger process of making .gnu_debuglink more safe (using e.g. sha256sum o anything considered secure at the time) and then using that... I'm unfortunately very selfish here as well as I have no time to work on this short term, but would be happy to help in the long run after taking the initial temperature as I think it's important to not trust random binaries downloaded on the internet. The process should be fairly straightforward: - agree on what kind of checksum we want and new section name (as I don't suppose .gnu_debuglink can change) ideally here I'd suggest embedding the hash algorithm in the section so it can evolve, e.g. `{sha256}<binaryhash>` or given it's small enough even as a string `sha256-0gotgQ4N0yE8WZbsu7B3jmUIZrycbqjEMxZl01JcJj4=` - add something similar to `objcopy --add-gnu-debuglink` to produce it; ideally make it possible to use both options together in a single pass. - add something to debuginfod to check after downloading a file if present (or optionally if deemed too costly) - convince distros to start producing using new objcopy option once it's available (I don't think that'll be difficult given I remember this was a concern multiple times on the fedora lists when debuginfod was first introduced) Thanks!
Relevant part of the fedora-devel thread at the time, justifying there'd be interest in distros: https://www.mail-archive.com/devel@lists.fedoraproject.org/msg166474.html (sorry for double-update, took me a bit to find that link)
Note that elfutils has impending patches (awaiting final review) for relaying and verifying RPM-IMA per-file crypto signatures: bug #28204. Fedora has been shipping these types of signatures since something like f37 or f38.
Interesting, thanks for the link! The implementation hurdle is a bit higher than updating the already-used objcopy command I was suggesting (won't be available for distros like debian that don't ship IMA data), but if available it's definitely a good alternative. As I understand that bz, the signature would be verified if available regardless of the kernel IMA setting, so for all fedora users as soon as it's available in debuginfod? I'll check the bz in more details and patch as time permits (probably next week)
Note that the main problem with this sort of scheme is not the checksum (whether CRC or a hash). That part can help provide some assurance against accidental corruption. (Plus you'd need external checksums for source files, which can't get additional ELF doohickeys inserted. But you'd need crypto signatures on those hashes in order to protect against deliberate corruption anywhere between the original build system and your client. That in turn requires distribution of crypto keys. It goes well beyond the objcopy stuff. I'm not sure whether the debian ecosystem has started thinking about this stuff, but when/if they do, debuginfod should be adaptable to pass on whatever assurances are possible.
debian has kept .gnu_debuglink (like fedora), so if we extend that to store a more reliable hash I believe that process should be fairly straightforward as they already must have an objcopy --add-gnu-debuglink command somewhere that could just be updated I haven't seen anything about IMA on debian though, so that'd likely come much later