Document "artifact rule" rationale

[lukpueh]

The recent discussion about whether and why we decided to replace the implicit DISALLOW * with an implicit ALLOW * when verifying expected materials and products makes it clear that we need to document these decisions more thoroughly.

in-toto/in-toto#43 shows how the current design of MATCH rules (only) evolved.

@SantiagoTorres suggests to create a Wiki that summarizes such on- and offline discussions and provides additional information about the rationale behind certain design decision that would go beyond the scope of the specification.

[reza-curtmola]

I missed all the discussion for the rationale why we prefer an implicit rule ALLOW * instead of a DENY * at the end of the artifact rules. Santiago mentioned that this is preferred because of the feedback received, which is mostly to improve usability.

I don't have a strong preference for either one, but I wanted to make sure that Justin is also on board with this choice.

[JustinCappos]

I don't remember the content of the discussion here, but do vaguely recall a discussion a long while back. We definitely need to document it in a way that others can see and chime in.

…

On Wed, Oct 11, 2017 at 5:11 PM, reza-curtmola ***@***.***> wrote: I missed all the discussion for the rationale why we prefer an implicit rule ALLOW * instead of a DENY * at the end of the artifact rules. Santiago mentioned that this is preferred because of the feedback received, which is mostly to improve usability. I don't have a strong preference for either one, but I wanted to make sure that Justin is also on board with this choice. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0XDySGHALDKIeWz_geM6fFgEe0WSLgks5srS72gaJpZM4Pymap> .

[lukpueh]

I think the main argument was that having to explicitly authorize (ALLOW) every material and product seems cumbersome, given that we mostly care for linking (MATCH) products of one step to the materials of the next step.
And that for a more restrictive layout, a project owner can always use an explicit DISALLOW * rule.

[JustinCappos]

I'd like to see some examples of this so we can better understand the implications.

If there is an explicit ALLOW *, doesn't this mean new items can effectively always be silently added?

[SantiagoTorres]

Sorry I missed this comment. I'll upload some examples soon to the repository's wiki to help us document these design decisions.

An explicit ALLOW * does indeed allow a step to register any products in their materials and products. Much like a firewall, I think having an explicit DISALLOW for good practice is a better decision than the opposite.

[JustinCappos]

Offhand, I'd rather have 1) an accidental annoyance from blocking something that is caught later and rectified before the software is shipped than 2) a situation where a compromised step can add any set of files they like, compromising any meaningful security guarantees. However, with some discussion, I may feel differently.

…

On Fri, Oct 27, 2017 at 5:56 PM, Santiago Torres ***@***.***> wrote: Sorry I missed this comment. I'll upload some examples soon to the repository's wiki to help us document these design decisions. An explicit ALLOW * does indeed allow a step to register any products in their materials and products. Much like a firewall, I think having an explicit DISALLOW for good practice is a better decision than the opposite. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0XD_AQcqsxaAiHJ3W8GnCv3Jaws3Ywks5swlGggaJpZM4Pymap> .

[lukpueh]

Below is a mostly exhaustive list of related historic and ongoing in-toto issues and PRs. It's worth combing through these, when rehashing the artifact rule rational.

• Ambiguous rule set: ALLOW foo while DISALLOW * is also a rule (Ambiguous rule set: ALLOW foo while DISALLOW * is also a rule #7)
• Matchrules: path expansion + verification changes + unittests (Matchrules: path expansion + verification changes + unittests in-toto#37)
• Fix MATCH rule ambiguities (Fix MATCH rule ambiguities in-toto#43)
• Major artifact rule update to align with specs (Major artifact rule update to align with specs in-toto#70)
• Adopt replace implicit DISALLOW with ALLOW (Adopt replace implicit DISALLOW with ALLOW in-toto#131)
• Remove implicit DISALLOW * from rule verification (Remove implicit DISALLOW * from rule verification in-toto#140)
• Revisit artifact rule path patterns (in-toto/in-toto#152)
• Add format schemas for artifact rules (Add format schemas for artifact rules in-toto#185)
• Support require artifact rule (Support require artifact rule in-toto#193)
• Fix firewall rules (Fix firewall rules in-toto#204)
• Fix illegal modification of artifact queue (Fix illegal modification of artifact queue in-toto#259)
• Rule verification false positives (Rule verification false positives in-toto#261)
• Major rewrite of artifact rule verification (Major rewrite of artifact rule verification in-toto#262)
• Add REQUIRE rule support (Add REQUIRE rule support in-toto#269)
• in_toto_verifylib: fix require/disallow queue (in_toto_verifylib: fix require/disallow queue in-toto#280)
• CNCF SIG Security recommends default terminal DISALLOW * rule (encode best practice in default rule behavior for DISALLOW * in-toto#287)
• Pseudocode for MATCH rule indicates that source and dest patterns can be distinct (Pseudocode for MATCH rule indicates that source and destination patterns can be distinct #19)
• Only the first rule for a given artifact in a list of rules has an effect. (Merge snapshot module and create_layout module into one layout-web-tool#49 (comment))
• Should the REQUIRE rule consume an artifact? (expected python in-toto to consume 'REQUIRE' layout item. #45)