Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 22 May 2020 18:00:12 -0400
From: Jeffrey Walton <noloader@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Short notes on qmail security guarantee

On Fri, May 22, 2020 at 8:19 AM Solar Designer <solar@...nwall.com> wrote:
> ...
> Writing code that avoids artificial limits yet is safe, is hard.  One
> way to do it is to avoid artificial limits throughout the code, but then
> impose them at a higher level, where they can be adjusted easily.  One
> such higher level is the operating system, but that makes the program's
> security dependent on its environment in this extra way (beyond many
> others) and with greater risk impact (worse than DoS).  Arguably, this
> makes the program unnecessarily fragile.  Another higher level would be
> within the program, like we see in Qualys' patch for qmail now.  This
> reduces the dependency of the program's security on its environment.

I don't use Qmail so I don't really have a dog in this fight, but ...
I'm not sure its a good idea to depend on another layer for security
properties, especially when a control is readily available. (re: the
first part of the paragraph).

Qmail should not depend on the operating system for security when it
is readily available to Qmail. In my mind's model, Qmail can remediate
this at the application level and has no need to turn to the operating
system at the platform level.

To drive the point home, consider an application that uses Apple iOS
4-digit PIN rather then a more proper authentication system that
requires sufficiently sized passcodes or phrases. Here, the
application's security depends on the operating system's security. ANd
many folks would not consider a 4 character PIN code sufficient for
authentication.

As another example, consider an application that depends upon
infrastructure for security instead of application security. Most
people would agree it would be a bad idea to forgo IPsec, VPN or TLS
because the infrastructure should be secure.

Another way I view it as a vulnerability in Qmail is, Qmail is
trusting the user for its security in a default state. Here, Qmail
trusts the user will set an appropriate limit on 32-bit platforms.
Trust is something you turn to when you don't have a security control
to place. But in this case there is a control to place - a sane
default limit inside Qmail.

Jeff

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.