On 11/3/25 12:58, Russ Allbery wrote: > Peter Gutmann <[email protected]> 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)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
