[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191119121910.g6tc5zwbmbdiuiuh@anathema>
Date: Tue, 19 Nov 2019 13:19:10 +0100
From: Morten Linderud <morten@...derud.pw>
To: oss-security@...ts.openwall.com
Subject: Re: Mitigating malicious packages in gnu/linux
On Tue, Nov 19, 2019 at 01:33:48PM +0200, Georgi Guninski wrote:
> As end user and contributor of gnu/linux, I am concerned about malicious
> packages (either hostile developers or hacked developers or another reason)
> and have two questions:
>
> * What do linux vendors to avoid malicious packages?
>
> * As end user what can I do to mitigate malicious packages?
Yo!
The answer to this is complicated. Different distributions has widely different
threat models and supply chains for dealing with packages. This can be from the
perspective of developers uploading pre-built binary packages to a repository,
then distributed. Another factor is distributions where source packages are
uploaded to a centralized builder, then distributed.
You also got source-based distributions, such as Gentoo and probably NixOS,
where the problem domain is a bit more complicated as the users might be
building the packages themselves.
Some attack vector are:
* A malicious build server
* Compromised source tarballs
* Compromised packagers
* Compromised mirrors/repositories
There is not a definitive solution here. But there are multiple efforts and
research going on. The most important one, in my opinion, is the reproducible
builds project [1]. We need to ensure we are not inserting random or
non-deterministic data into our build artifacts. This stretches from upstream
developers providing tarballs, to pre-compiled sources and packages from
distributions. There is no distribution today that has full reproducible builds,
but there are many projects that work towards this and work on reproducible
builds.
Arch Linux has recently been trying to get the core repository 100%
reproducible, and we have done a lot of effort towards this just the past week
[2]. I have also written up a blog post describing the effort that has gone into
this [3].
There are also other efforts, like Benjamin Hof which has done work attempting
to provide transparency logs for Debian package repositories. This can work as a
guard detecting compromised signing keys. Either from build servers or packagers [4].
The current status quo is a bit grim. You can't protect yourself against
malicious packages. You need to trust the source and build the packages
yourself, preferably write your own package files.
As long as we use distributions we are bound to trusting the packagers and
believe they are doing the right thing. However, reproducible builds will allow
users to verify the work done by packagers in the future.
I hope this gives some insight and answers parts of your question :)
[1]: https://reproducible-builds.org/
[2]: https://lists.archlinux.org/pipermail/arch-dev-public/2019-November/029721.html
[3]: https://linderud.dev/blog/reproducible-arch-linux-packages/
[4]: https://debconf18.debconf.org/talks/104-software-transparency-package-security-beyond-signatures-and-reproducible-builds/
--
Morten Linderud
PGP: 9C02FF419FECBE16
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
