[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<ME0P300MB0713899B74FA8CA28A6C6868EECDA@ME0P300MB0713.AUSP300.PROD.OUTLOOK.COM>
Date: Thu, 13 Nov 2025 02:19:50 +0000
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: Russ Allbery <eagle@...ie.org>
CC: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Questionable CVE's reported against dnsmasq
Russ Allbery <eagle@...ie.org> writes:
>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. :)
It's actually really hard to write something that covers all the cases,
particularly when you're dealing with unrealistic threats. For example for
the config data the text for my code is:
-- Snip --
cryptlib makes certain assumptions about the environment in which it operates,
most of which are common-sense ones such as an attacker not having
operating-system-level control of the system on which cryptlib is running. In
terms of trust boundaries, cryptlib assumes that data like cryptlib keysets
and configuration files stored on the system can only be modified by a source
trusted at the same level that cryptlib is operating at. For non-cryptlib
keysets like PGP and PKCS #12 ones which come from an external source,
cryptlib assumes that the user has verified the data in them before cryptlib
uses it.
-- Snip --
But in some cases you get into "here is something totally impractical/
unrealistic/stupid a user could do [0], this isn't considered part of the
threat model", and you're down to trying to enumerate all the stoopid and
exclude it from the threat model.
Peter.
[0] For example modify the code/operating environment to introduce a security
vulnerability, I'll let you decide whether this qualifies as impractical,
unrealistic, stupid, or several of the above.
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.
