Security model

[sdboyer]

To date, we've generally deferred the harder security questions in the interest of figuring out what we actually want the tool to be. With the basic vision now settled, security is now at the forefront of our considerations.

To start, we need to articulate a security model for dep; this is just a stub/sketch to get us started.

The essential task of a dependency management system is to select and reproduce a dependency set. Selection should avoid versions of code known to have vulnerabilities, and reproduction should be byte-level precise.

In functional terms, this means a few things:

• Verifying the integrity of code on disk against an expected hash digest (related: Vendor pruning #120)
• Verifying the authenticity of code retrieved from a source over the public internet
• Tracking security issues with and black-listing of released versions (more or less Security service #176)

We needn't necessarily ship a security service as part of 1.9 - speccing and prototyping it is probably sufficient.

[sdboyer]

/cc @Alex-Wauters

[sdboyer]

also maybe of interest to @raggi

[raggi]

Please review the vectors in the TUF papers. We may not be getting into distribution immediately, but in any case, the threat model documented there applies wholesale to users.

[raggi]

I'll also say here, as it's not written down prominently and concisely anywhere:

During the rubygems yaml scare, the only way we asserted user safety in a tenable timeline was by comparison of fast processed content hashes from known trusted mirror data sets. Specifically a number of us had access to write-only and/or older partial data sets that we used to generate md5, sha1, and sha256 of. We got results about potential tampering very quickly this way, and it didn't require a ton of sophistication. One of the most important things a distributor can do is to post content hashes in a place that is hardened against tampering and ideally replicated by unrelated actors.

TUF provides a ton more than that, but the above is the reality from a real world scare.

[titanous]

A big +1 to TUF. It's worth noting that we already have a Go implementation and sorting out the CLA/licensing for the existing code would not be an issue if there is interest in bring it upstream.

[sdboyer]

Ah yes, TUF - I read the spec last fall, but hadn't revisited it yet. As @raggi noted, the issue with TUF is it's designed around the idea of having upstream code repositories. That puts it out of our reach, at least until we get into building code hosting services, a la discussion in #174.

Until then, the best we can do is try to cover the vectors they describe as best we can, and try to aim our implementation in a direction that would make it not terribly painful to integrate such central repository services later. @titanous, I think guidance from Flynn folks would be very helpful on the latter front 😄

For other folks' reference, here's the vectors described in the TUF spec:

1.5.2. Goals for specific attacks to protect against

   Note: When saying the framework protects against an attack, this means that
   the attack will not be successful.  It does not mean that a client will
   always be able to successfully update during an attack.  Fundamentally, an
   attacker positioned to intercept and modify a client's communication will
   always be able to perform a denial of service.  The part we have control
   over is not allowing an inability to update to go unnoticed.

   Arbitrary installation attacks. An attacker installs anything they want on
   the client system. That is, an attacker can provide arbitrary files in
   response to download requests and the files will not be detected as
   illegitimate.
   
   Endless data attacks.  Attackers should not be able to respond to client
   requests with huge amounts of data (extremely large files) that interfere
   with the client's system.
   
   Extraneous dependencies attacks.  Attackers should not be able to cause
   clients to download or install software dependencies that are not the
   intended dependencies.
   
   Fast-forward attacks.  An attacker arbitrarily increases the version numbers
   of project metadata files in the snapshot metadata well beyond the current 
   value, thus tricking a software update system into thinking any subsequent
   updates are trying to rollback the package to a previous, out-of-date version.
   In some situations, such as those where there is a maximum possible version
   number, the perpetrator could use a number so high that the system would
   never be able to match it with the one in the snapshot metadata, and thus
   new updates could never be downloaded.
   
   Indefinite freeze attacks.  Attackers should not be able to respond to
   client requests with the same, outdated metadata without the client being
   aware of the problem.
   
   Malicious mirrors preventing updates.  Repository mirrors should be unable
   to prevent updates from good mirrors.
   
   Mix-and-match attacks.  Attackers should not be able to trick clients into
   using a combination of metadata that never existed together on the
   repository at the same time.

   Rollback attacks.  Attackers should not be able to trick clients into
   installing software that is older than that which the client previously knew
   to be available.

   Slow retrieval attacks.  Attackers should not be able to prevent clients
   from being aware of interference with receiving updates by responding to
   client requests so slowly that automated updates never complete.
   
   Vulnerability to key compromises. An attacker who is able to compromise a
   single key or less than a given threshold of keys can compromise clients.
   This includes relying on a single online key (such as only being protected
   by SSL) or a single offline key (such as most software update systems use to
   sign files).

   Wrong software installation.  An attacker provides a client with a trusted
   file that is not the one the client wanted.