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 [email protected] 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 https://github.com/in-toto/docs/issues/4#issuecomment-335949742, 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 [email protected] 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 https://github.com/in-toto/docs/issues/4#issuecomment-340105122, 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 (#7)
• Matchrules: path expansion + verification changes + unittests (in-toto/in-toto#37)
• Fix MATCH rule ambiguities (in-toto/in-toto#43)
• Major artifact rule update to align with specs (in-toto/in-toto#70)
• Adopt replace implicit DISALLOW with ALLOW (in-toto/in-toto#131)
• Remove implicit DISALLOW * from rule verification (in-toto/in-toto#140)
• Revisit artifact rule path patterns (in-toto/in-toto#152)
• Add format schemas for artifact rules (in-toto/in-toto#185)
• Support require artifact rule (in-toto/in-toto#193)
• Fix firewall rules (in-toto/in-toto#204)
• Fix illegal modification of artifact queue (in-toto/in-toto#259)
• Rule verification false positives (in-toto/in-toto#261)
• Major rewrite of artifact rule verification (in-toto/in-toto#262)
• Add REQUIRE rule support (in-toto/in-toto#269)
• in_toto_verifylib: fix require/disallow queue (in-toto/in-toto#280)
• CNCF SIG Security recommends default terminal DISALLOW * rule (in-toto/in-toto#287)
• Pseudocode for MATCH rule indicates that source and dest patterns can be distinct (in-toto/docs#19)
• Only the first rule for a given artifact in a list of rules has an effect. (https://github.com/in-toto/layout-web-tool/pull/49#discussion_r510277345)
• Should the REQUIRE rule consume an artifact? (https://github.com/in-toto/docs/issues/45)