Re: New service: https://debuginfod.debian.net
Frank's original reply didn't make it to the list for some reason and
has also gone missing on his end so resending on his request.
On Wed, 2021-02-24 at 15:23 -0500, Frank Ch. Eigler wrote:
---
Hi, Ian -
ijc wrote:
> [...]
> What are the security implications for users/clients of using this or
> more importantly enabling it by default?
Good questions. (I'm a debuginfod upstream developer.)
> Presumably clients have to trust that the server is not going to feed
> them malicious debug info. Are the tools which consume this information
> written to operate on completely untrusted inputs? It seems like many
> of them could have been written historically with the assumption that
> their inputs are mostly to be trusted. I suppose the use https helps
> mitigate this at least a bit when it comes to a debian.{org,net}
> service.
Indeed, technical measures like packaging level crypto-signatures become
inapplicable, since individual files are transferred. However, IMHO the
concern is substantially mitigated, if distro users connect securely to
trusted servers that index trusted content.
> What about information leakage? apart from debugids does this leak
> anything else to the server? On a quick look it seems like it might
> potentially leak source code paths (at least the leaf bits) to things
> being debugged -- does this mean that if a user is debugging private
> software (perhaps unpublished or perhaps proprietary software for
> $work) on a Debian system they are at risk of leaking the source
> filenames if they run gdb on one of their binaries while debugging?
> This might be a problem if it comes to enabling this transparently.
Yes, it might. On the other hand, this is mitigated by a few aspects.
Mainly, debuginfod clients like gdb only call out to the system in case
they have failed to look up the needed data another way. So if you're
debugging local software built normally, the buildids / source names
won't leak because the debugger will find them locally, and debuginfod
servers are not consulted.
Users who debug secret software but still wish to use internal
debuginfod distribution for it, can do so by setting up a personal
debuginfod instance whereever the secret stuff is held, and configure
that server to federate upstream to the public server. That way, the
public server will only see traffic that the local one couldn't satisfy.
Do these considerations overcome the concerns, so as to provide a
comfortable out-of-the-box experience for most users?
- FChE
Reply to: