[PLUG] Is a Linux Distro compromised?

Mike C. mconnors1 at gmail.com
Tue Oct 8 15:36:52 UTC 2019


in many cases, it's NOT the "real" kernel as published by The Linux
Foundation: Red Hat and Debian, at least and for sure, maintain their own
patch sets for the kernel.

They do publish them, of course, because the license requires it, but the
resulting binary is definitely not what was running in a Linux Foundation
test server.

-- Now we're having the convo I'm seeking. I'm familiar with kernel patches
and have applied them in previous life as small time Debian LAMP server
admin.

I've always thought kernel patches were additive chunks of code that
extended some core functionality. This goes way back to my days of learning
about Unix architecture and philosophy.

So my assumption is that distro developers aren't re-writing kernel code on
the fly per distro release, but instead submit kernel code changes to
kernel maintainers.

I haven't done Linux Server Admin work in over a decade and I'm not a
developer. I rarely run any Linux/FOSS apps besides a web browser, terminal
and Signal.

To that end I've found myself moving away from running clunky Debian-stable
to lighter weight distros with more "modern" desktop enviros. As it all
just works, I don't get under the hood and don't question things much.

But I also don't stray too far from Debian. It has been on the Internet
front lines for decades.

So, the $64,000 question is, if I'm running a Debian based distro that is
based on Debian's Stable branch but has it's own Desktop Envrio but is
developed in a country that is very well known for its surveillance state,
can I trust the output of the uname -r "4.15.0-33-generic" that is in fact
what is running on my computer?

Maybe I'm getting off in the weeds a bit here, but I'm wondering if there's
or should be a mechanism where the kernel running on a computer can be
compared to the upstream source kernel image.

Or are we left to trust the sanctity of our running kernels to the many
eyes of the Linux community, root kit tools and security researchers to
discover kernel tampering?

-- Mike








>
>



More information about the PLUG mailing list