[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b9817c28-053f-49a9-94f8-36b497da23ce@gmail.com>
Date: Mon, 3 Nov 2025 14:10:12 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: oss-security@...ts.openwall.com, Russ Allbery <eagle@...ie.org>,
Peter Gutmann <pgut001@...auckland.ac.nz>
Subject: Re: Questionable CVE's reported against dnsmasq
On 11/3/25 12:58, Russ Allbery wrote:
> Peter Gutmann <pgut001@...auckland.ac.nz> writes:
>
>> Even before getting into that, how do you document that people shouldn't
>> do certain things with their config files, or by extension which bits
>> are inside and outside the security boundary? "If an unauthorised party
>> can modify your config files then bad things can happen" seems
>> redundant, "We take no responsibility for what happens if you fail to
>> take unspecified steps to secure your config files" might be correct but
>> will be perceived as blame-the- victim... how do you document this for
>> users?
>
> This is true. Helping users understand trust boundaries is probably the
> hardest part of writing effective security documentation. They can be very
> complicated and even many security people struggle with security boundary
> analysis.
(snip)
> The implication is that if you want to generate a configuration from some
> untrusted source, ensuring that configuration is fully trusted and vetted
> and will parse correctly and will not trigger any bugs in the software is
> 100% your problem, not my problem as the software maintainer, and any
> security issues that result will not be accepted as CVEs because this is
> not a feature the software provides.
>
> This is not a particularly *friendly* policy, because that sort of
> verification is hard (and is very likely to break in insecure ways with
> future software releases), but I think it's a fairly *realistic* policy
> for a lot of single-maintainer free software projects that gets one out of
> the rather terrifying world of attempting to reason about a complex and
> porous security boundary.
>
> I'm probably overcomplicating this problem by combining it with the
> problem of how to describe a more complicated security boundary, and my
> problem can probably be addressed by relatively simple declarations in the
> documentation and SECURITY.md. :)
What if there was a way to direct security vulnerabilities reported
in certain cases to someone other than the main maintainer? I think
this would be very useful for Linux filesystems: Google cares about
crafted F2FS and ext4 images, but upstream doesn't. It would also
work in use-cases like this one: such reports would be directed at
whoever maintains the config generator.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
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.
