Re: Three steps we could take to make supply chain attacks a bit harder

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Mar 30, 2024 at 09:37:44AM +0000, 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.

I've noted many times before how inconsistent it is that many
of us will happily mock a website saying "curl <url> | sh -",
and then with a straight face tell users to download a tarball
and run the 1 MB auto-generated 'configure' shell script that
is obfuscated to the point of unreadability by autotools. It
is the perfect place to hide malicious code in tarballs. 

> 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.

This is challenging to address too, since often the 'm4/' directory
contains a mixture of application provided m4 files, and autotools
provided m4 files. You can't blindly purge the m4/ directory. They
could have provided a "m4/my-build-to-host.m4" file that interferes
or overides the main 'm4/build-to-host.m4'. So even if autoreconf
did regenerate that file as desired, you're still not entirely
safe.

Still, it would be good practice to have a way to purge any files
that are known to be autoconf provided, so at least you know which
remaining files to look at for threats / problems.

> (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.

Be honest about which platforms you genuinely need portability
too in the modern world. Cull obsolete / dead platforms.

While it is a fun intellectual challenge to write portable code
against POSIX, most projects are better off not reinventing the
wheel. Something like GLib takes out a large part of the portability
pain if you really must stick with developing C, and is easy to
adopt incrementally. This is what let libvirt cull its use of
gnulib, which in turn lets us cull the use of autotools

> 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-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD).



> 
> 
> (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.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
> --
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux