search

in-toto / ITE

in-toto Enhancements
Other
19 stars 15 forks source link

ITE-4: Expand motivation 3 to CNAB bundles; add ITE-4 to README's drafts section #9

Closed adityasaky closed 4 years ago

adityasaky commented 4 years ago

Also updates the prototype implementation section to point to basic proof-of-concept resolver for CNAB bundle.json files.

trishankatdatadog commented 4 years ago

So, in our quest to try to encapsulate a CNAB use-case, @adityasaky and I learned something interesting today.

We were trying to use JsonPath as a way to express exactly which parts of a CNAB a machine is allowed to modify. However, we quickly found out that the metacharacters of JsonPath conflict with fnmatch, which is what python-in-toto uses to (partly) implement "bash-style wildcards".

The question is whether bash-style wildcards are too limiting, especially in the context of ITE-4, which is intended to generalize artifacts from beyond files to arbitrary resources with URIs. There are at least two options for fixing this:

  1. ITE-4 should make it clear that no implementation must use anything other than bash-style wildcards for pattern matching.
    1. Pros: security has been fully analyzed.
    2. Cons: potentially limits interesting use cases, such as the one above.
  2. Open in-toto verifiers to accepting user-specified filter() functions which implement arbitrary pattern matching (e.g., JsonPath).
    1. Pros: opens up interesting use cases, such as the one above.
    2. Needs thinking about security implications. For example, arbitrary regexes can open up algorithmic complexity attacks. Furthermore, the security in-toto verification now depends on user input.

So far, this is an interesting question that we believe deserves at least some discussion. Let us know what you think here.

Cc @radu-matei @jlegrone @squillace

adityasaky commented 4 years ago

Thanks for summarizing, @trishankatdatadog!

I'm currently leaning towards option 1, at least with the scope we've considered right now. I believe that opening up filter() requires far more discussion and thought, probably enough for it to be an ITE of its own? Just a thought. I also believe that swapping filter() is not necessarily linked to situations involving abstract resources, so it shouldn't be bundled with ITE-4. In fact, I wonder if we'd end up evaluating some popular options individually and talking about how they should be used / what considerations implementations must make etc. Such an ITE would also probably greatly benefit from the lessons learned as we continue working on ITE-4 use cases + their resolvers...

adityasaky commented 4 years ago

For now, I've updated the CNAB resolver PoC to remain friendly with bash-style patterns, meaning it'll work okay with fnmatch, and verification passes (with DISALLOW * this time :wink:).

SantiagoTorres commented 4 years ago

LGTM. Thanks!