|
Message-ID: <CAH8yC8k1=bzu9N3-x8NXLesjbb07tYpkwWgx0Bkoo=d44N2Nhg@mail.gmail.com> 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.