oss-sec mailing list archives
Re: Mitigating malicious packages in gnu/linux
From: Solar Designer <solar () openwall com>
Date: Wed, 20 Nov 2019 13:44:25 +0100
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
Current thread:
- Mitigating malicious packages in gnu/linux Georgi Guninski (Nov 19)
- Re: Mitigating malicious packages in gnu/linux Morten Linderud (Nov 19)
- Re: Mitigating malicious packages in gnu/linux Stuart D. Gathman (Nov 19)
- Re: Mitigating malicious packages in gnu/linux Tim Kuijsten (Nov 19)
- Re: Mitigating malicious packages in gnu/linux Ludovic Courtès (Nov 19)
- Re: Mitigating malicious packages in gnu/linux Morten Linderud (Nov 19)
- Re: Mitigating malicious packages in gnu/linux Pavel Heimlich (Nov 19)
- Re: Mitigating malicious packages in gnu/linux Jakub Wilk (Nov 19)
- Re: Mitigating malicious packages in gnu/linux Solar Designer (Nov 20)
- Re: Mitigating malicious packages in gnu/linux Russ Allbery (Nov 20)
- Re: Mitigating malicious packages in gnu/linux Solar Designer (Nov 20)
- Re: Mitigating malicious packages in gnu/linux Mark Hatle (Nov 20)
- Re: Mitigating malicious packages in gnu/linux Russ Allbery (Nov 20)
- Re: Mitigating malicious packages in gnu/linux Aditya Sirish Arunkumar Yelgundhalli (Nov 20)
- Re: Mitigating malicious packages in gnu/linux Bob Friesenhahn (Nov 20)
- Re: Mitigating malicious packages in gnu/linux Jeremy Stanley (Nov 20)
- Re: Mitigating malicious packages in gnu/linux Bob Friesenhahn (Nov 20)
- Re: Mitigating malicious packages in gnu/linux Morten Linderud (Nov 19)