Re: Questionable CVE's reported against dnsmasq

[Demi Marie Obenour <demiobenour () gmail com>]

On 11/3/25 12:58, Russ Allbery wrote:
> Peter Gutmann <pgut001 () cs 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)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature