Regarding downstream defense, prohibiting blobs or differences between
tars and git repos may be overkill or difficult at this moment, but a
tool to assist maintainers in the identification and analysis of these
situations where attacks may be hidden into can be very helpful.
Regarding the latter, where you want to find diff between tars and git
repo content, someone may say "let's just use the github API to pull the
tar", but not all projects use github, or have that feature. So, I still
think there is value in these tools.
I started working on a PoC personal minitool named rpmseclint that
utilizes the "VCS" tag to pull the git repo, and the tar, and compares
and flags things for further review. Right now, I'm just focused on
blobs, and files/directories differences. The intention is to use it at
least right before a rebase. I'm just planning to personally use it to
get a "feel" for it (and help myself), but open to anyone wanting to
explore this idea.
In general, I think the idea of codifying security practices expertise
in tools to assist maintainers with detection and analysis has great
value; even if it is not enforcing anything at the moment. The
maintainer could then explicitly add found problems to an "ignore" list
after the analysis, and explain the "why" in the git commit body
message, and perpetuate the reasoning in the git history of the
downstream project. There is already a lot of best practices codified in
the gating pipelines, and I have found them extremely useful myself.
Regards,
Carlos R.F.
On 3/30/24 02:37, Richard W.M. Jones wrote:
I'm not pretending these will solve everything, but they should
make
attacks a little harder in future.
(1) We should routinely delete autoconf-generated cruft from upstream
projects and regenerate it in %prep. It is easier to study the real
source rather than dig through the convoluted, generated shell script
in an upstream './configure' looking for back doors.
For most projects, just running "autoreconf -fiv" is enough.
Yes, there are some projects that depend on a specific or old version
of autoconf. We should fix those. But that doesn't need to delay us
from using autoreconf on many projects today.
In the xz case this wouldn't have been enough, it turns out we would
also have to delete m4/build-to-host.m4, which then autoreconf
regenerates. I don't fully understand why that is.
(2) We should discourage gnulib as much as possible.
In libvirt we took the decision a few years ago to remove gnulib.
It's extremely convoluted and almost no one understands how it really
works. It's written in obscure m4 macros and shell script.
It's also not necessary for Linux since gnulib is mainly about
porting to non-Linux platforms. There are better ways to do this.
In the xz case it was a gnulib-derived script which was modified to do
the initial injection (original:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-ho...).
(3) We should have a "security path", like "critical path".
sshd is linked to a lot of libraries:
/lib64/libaudit.so.1 audit-libs
/lib64/libc.so.6 glibc
/lib64/libcap-ng.so.0 libcap-ng
/lib64/libcap.so.2 libcap
/lib64/libcom_err.so.2 libcom_err
/lib64/libcrypt.so.2 libxcrypt
/lib64/libcrypto.so.3 openssl-libs
/lib64/libeconf.so.0 libeconf
/lib64/libgcc_s.so.1 libgcc
/lib64/libgssapi_krb5.so.2 krb5-libs
/lib64/libk5crypto.so.3 krb5-libs
/lib64/libkeyutils.so.1 keyutils-libs
/lib64/libkrb5.so.3 krb5-libs
/lib64/libkrb5support.so.0 krb5-libs
/lib64/liblz4.so.1 lz4-libs
/lib64/liblzma.so.5 xz-libs
/lib64/libm.so.6 glibc
/lib64/libpam.so.0 pam-libs
/lib64/libpcre2-8.so.0 pcre2
/lib64/libresolv.so.2 glibc
/lib64/libselinux.so.1 libselinux
/lib64/libsystemd.so.0 systemd-libs
/lib64/libz.so.1 zlib / zlib-ng
/lib64/libzstd.so.1 zstd
Should we have a higher level of attention to these packages? We
already have "critical path", but that's a broad category now. These
seem like they are "security path" packages, an intentionally small
subset associated with very secure services which are enabled by
default.
These are just my thoughts on a Saturday morning. Feedback welcome of
course.
Rich.