ppkarwasz opened a new pull request, #32:
URL: https://github.com/apache/logging-site/pull/32

   Restructures the "Data sources" section of the common threat model into a 
**Sources** section organised by *who controls* each input, rather than a flat 
trusted/untrusted split.
   
   The three categories are defined by their controller:
   
   * **Configuration (operator-controlled, trusted)**: environment variables, 
configuration properties, and configuration files, with the existing deployer 
responsibilities.
   * **Structural identifiers and control (developer-controlled, trusted)**: 
logger names, levels, markers, the identifiers and field names of a structured 
log message (for example the RFC 5424 `MSGID` and `SD-ID` fields), and the 
format string of a parameterized log statement.
   * **Content (user-controlled, untrusted)**: log messages, the string 
representation of log parameters, and thread context **values**.
   
   ## Why
   
   Triaging recent reports showed that reporters have a difficulty into 
classifying sources correctly, such as the structural identifiers of a 
structured message. Organising sources by controller makes the trust 
classification explicit and gives a clean basis for deciding which reports are 
in scope.
   
   It also lets the model state the remediation rule that follows from the 
classification: trusted inputs **may** be rejected (fail-fast, for example by 
throwing), while user-controlled content **must** be accepted and never 
rejected, since rejecting it would turn a malicious value into a denial of 
service.
   
   ## Thread context keys
   
   Thread context **values** are classified as untrusted content. The trust 
level of thread context **keys** is deferred to discussion 
apache/logging-log4j2#4132 and marked in the document as a known open gap, 
rather than silently choosing a side.
   
   ## Dependent changes
   
   * The adversary-capabilities section now references the new content 
subsection, drops thread context keys from the in-scope channels pending the 
discussion above, and marks an adversary who controls developer-controlled 
structural or control inputs as out of scope.
   * Internal cross-references updated to the new subsection anchors; the 
parent `#threat-common-sources` anchor is retained.
   
   ## Out of scope for this PR
   
   Sink-side concepts (structured versus unstructured layouts, active versus 
passive sinks, and downstream-destination trust) are intentionally left for a 
follow-up PR.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to