oss-sec mailing list archives
Re: Mitigating malicious packages in gnu/linux
From: Bob Friesenhahn <bfriesen () simple dallas tx us>
Date: Wed, 20 Nov 2019 15:08:58 -0600 (CST)
On Wed, 20 Nov 2019, Jeremy Stanley wrote:
On 2019-11-20 13:28:04 -0600 (-0600), Bob Friesenhahn wrote: [...]Modern GNU/Linux systems have far too much executing code to reasonably secure. Paring down the amount of executing code helps quite a lot with improving security.In your opinion, how does this compare with proprietary operating systems? Do they have more or less code executed than modern GNU/Linux systems (or can we even know)? How about the popular BSD Unix derivatives? What is your benchmark for the correct amount of code to be executed, or is this analysis based on comparison with an abstract ideal operating system archetype?
These are all good questions.I use OmniOSce (a free-software Sun Solaris/SVR4 server derivative), and it claims (https://omniosce.org/setup/freshinstall) to require 8GiB of space but I recall an original install of less than 4GiB. A Ubuntu 18.04 KDE desktop system here (Kubuntu) used for software development seems to be consuming about 20GiB of space.
I work on dedicated Linux-based systems where the root filesystem takes just 16MiB (compressed) of space (19MiB including boot firmware). Linux-based systems are still able to boot and run from a CD.
BSD systems which are used as firewalls or for dedicated functions can be quite small.
The amount of software installed and running on Linux systems continues to grow rapidly, and tend to defeat the end user from understanding the purpose or even being aware of the existence of the applications. With a great many libraries and applications brought in as metapackage dependencies, the security exposure of typical Linux desktop systems seems quite high.
A secure system should do almost nothing by default with each service enabled only starting absolutely required software to perform the function. Functionality should be incrementally enabled. This is not what modern Linux desktops are like.
Regardless, the source for these systems is the original source code and a defect or malign intent of the source code can bring down the whole system.
Bob -- Bob Friesenhahn bfriesen () simple dallas tx us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Current thread:
- Re: Mitigating malicious packages in gnu/linux, (continued)
- 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)