Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 20 Nov 2019 15:08:58 -0600 (CST)
From: Bob Friesenhahn <>
Subject: Re: Mitigating malicious packages in gnu/linux

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

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 Friesenhahn,
GraphicsMagick Maintainer,
Public Key,

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.