[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191120124425.GA25554@openwall.com>
Date: Wed, 20 Nov 2019 13:44:25 +0100
From: Solar Designer <solar@...nwall.com>
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?
Back when Openwall GNU/*/Linux was being actively developed, I used to
review each contributor's changes before making them public. I also
(re-)verified authenticity of third-party source tarballs instead of
blindly trusting whatever the contributor could have uploaded to us.
(I'd do the same now, but without active development there's simply
nothing to review lately.)
Of course, this approach doesn't scale as-is (with just one person to
review and publish everything) to larger distros, but some kind of peer
review can and should be present.
> * As end user what can I do to mitigate malicious packages?
Try to install only what's needed, or not a lot more than what's needed.
(Can't be done perfectly with larger distros and their dependency hell.)
Contrary to traditional best practices, update only what and when needs
to be updated. (Of course, you take responsibility to watch for any
relevant security updates, or accept the risk if you neglect to do that.
You also miss silent security fixes, but on the other hand you similarly
miss newly introduced vulnerabilities.)
Use a long-term support distro, preferably starting half-way into its
lifetime when updates are already infrequent. (Similar risk of missing
silent security fixes in new upstream versions, but also avoiding new
vulnerabilities.)
Setup packet filters with blocking and logging of unexpected outbound
packets, including to console so that you'd notice.
Setup custom anomaly detection and actually watch it - e.g., for new
programs running that haven't ever run before, etc.
Use multiple pseudo-user accounts (doesn't protect against issues in
packages' pre/post-install scripts, etc.), containers, VMs - but even
then you have the risk of getting the same malicious package in multiple
VMs, which e.g. on Qubes OS could happen through updating a template VM.
Alexander
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.
