RFE: please provide possibility to build procdump against system installed libbf about procdump-for-linux

[MarioHewardt]

We'll tag this as a future enhancement to make sure we're tracking it.

[kloczek]

Coming from an information security background, that was precisely the "con" I was referring to. Great minds ;)

Ok .. my mistake. For some reasons I had of impression that your opinion is kind of opposite.
One more time .. sorry 👍 😄

[MarioHewardt]

Hi - We statically build and link against the version of libbpf that we need during build. Is there a reason you need this to build against system installed libbpf? There is a myriad of different versions out there and we may not be able to build against them.

[kloczek]

Reason always in such cases is the same.
In case finding any new bug in exact library all what is needed is fixing and rebuilding package with that library without rebuilding anything which issues static linking.

Currently in our distro libbpf is used by

[tkloczko@pers-jacek SPECS]$ grep libbpf * -l | grep -v libbpf.spec
bcc.spec
bpftrace.spec
criu.spec
kernel-tools.spec
libabigail.spec
systemd.spec
v4l-utils.spec

So it make sense to have and use only shared libbpf.

[MarioHewardt]

How do you handle version dependencies in your distro with potentially breaking changes? For example, if ProcDump requires version X and criu requires version Y (with breaking changes between the two). I can certainly provide the option of using system installed libbpf and check version at build time. If for some reason it's not available, fall back to static linking.

[kloczek]

Using pkgconfig handless all those cases.

[kloczek]

Meson, cmake, GNU autotools provides well designed interface with pkgconfig.
IMO you should consider start use one of those build frameworks instead maintaining custom set of Makefile files .. only because it is waste of time maintaining that.

[mzpqnxow]

static

Not intending to hijack the issue here (and I will certainly create another issue if it makes sense - probably depending on the response) but is there any reason you don't make a fully statically linked exe available for the sysinternals tools for Linux?

(I'm fully aware of the pros/cons, just curious if there are any technical reasons - I will give it a try doing a static build myself when I have a chance)

Thanks!

[kloczek]

is there any reason you don't make a fully statically linked exe available for the sysinternals tools for Linux?

Yes. Because now ALL Linux distribution are trying to avoid by any cost any static linking.
In case of any issue with affected library it is necessary to fix it and provide new package. In case of static linking it is necessary to rebuild all packages linked with that buggy static library.

[mzpqnxow]

is there any reason you don't make a fully statically linked exe available for the sysinternals tools for Linux?

Yes. Because now ALL Linux distribution are trying to avoid by any cost any static linking. In case of any issue with affected library it is necessary to fix it and provide new package. In case of static linking it is necessary to rebuild all packages linked with that buggy static library.

Coming from an information security background, that was precisely the "con" I was referring to. Great minds ;)

... that, plus a potential loss of ASLR (though that one is no longer a concern for users with systems that have PIE toolchains)

Those said, I personally believe procdump to be somewhat exceptional with regard to the potential necessity/benefit of offering a statically linked release - because it is often used for quick and dirty "best-effort" forensics, post-intrusion. This leads into the "pro" I was referring to...

Specifically, with post-intrusion live forensics, it's HIGHLY desirable (if not an absolute requirement) that any tools used on a compromised system avoid the possibility of being subverted by adversary modified shared libraries. There's a glut of low-sophistication LD_PRELOAD based "rootkits" out there that can be very annoying if you need to investigate in the compromised userland environment with tools that are dynamically linked. The only real way around this problem (aside from doing it "properly", at a different level than userland) is bringing your own statically linked executables to the system

Of course there's always the (very real) risk that the kernel (or worse) is subverting you as well - depending on the situation - and whenever possible memory acquisition should be done in ring-0, hypervisor, SMM, or whatever you may happen to have at your disposal. But, sometimes you have to make do with what you have ;)

If you're curious, here's two pieces of information; these are not necessarily intended to support the idea that a statically linked exe would be nice, nor to go against it. Just what I learned after spending 10 minutes building a statically linked exe myself. Pardon me if they're common sense

1. procdump does seem friendly to static linking; I built it as a static ELF in ~5 minutes. The caveat - I only tested the most basic use-case to declare "looks good" (dumping a process by ID with no flags). My main concern before testing was that there might be some fundamental dependency on dlopen/dlsym of libraries for some functionality, which can be problematic with statically linked executables
2. The runtime shared libraries (per the ELF markings at least) are libz, libelf, and then the handful of the usual libc suspects (e.g. libstdc++, libm, libgcc, libc)

Aaaanyway.. given there wasn't any hassle in producing a statically linked ELF by building it myself, I won't push the issue any further unless the maintainers decide for some reason they would like to

Thanks for the quick dialogue and sorry for the distraction!

[kloczek]

Looks like 3.2.0 provides possibility to build against system installed libbpf.
Feel free to close this ticket if nothing more outsatnding is on your list related to this ticket.

Thank you.