[ocaml-platform] Secure OPAM?

[Louis Gesbert]

Indeed, we'd better get some security concerns before it becomes an issue ;

Let me point what feels like weak areas at the moment:
* No restriction on what the package scripts can do (other than running as user). Not writing outside of the switch prefix would be a good start, but that's more a concern of preventing mistakes than real security since you install executable code there anyway.
* No repo or package signing. What we have at the moment is only:
  - metadata downloaded through HTTPS (no specific certificate constraint)
  - checksums on client-downloaded metadata (MD5, generated on the server by opam-admin)
  - (non-mandatory) MD5 checksums on downloaded archives (verified by the client, OR by the mirroring server, which will then happily put a valid MD5 on the repackaged archive -- to be checked)
  - no extra checks done on the other available repository or package upstream kinds (rsync, git, etc.)
This was originally designed as a way to check the integrity of downloads and detect changes, not as a security mesure.
* Handling of external dependencies: a bit out of the scope here, but we need to push on the discussion on the design of this, it's at the moment underspecified ; of concern here, there is a feature that allows to specify a URL in the "depexts" field that will be downloaded and executed by opam-depext (mine or Anil's) without any check. Not sure what to do with that.

So yes, signing of packages would be a good start, but there are many possibilities ; assuming the Github repo is trusted (as well as the link between that and opam.ocaml.org), having opam-admin add some signatures and the OPAM client check those would certainly go in the right direction while remaining somewhat light. Asking contributors to sign their pull-requests, as mentionned in the LWN article forwarded by Gabriel, is another story (we could be using 'git tag --sign' and integrating that into opam-publish, for example).

Cheers,
Louis

> - Anil Madhavapeddy, 18/01/2015 21:11 -
> [+opam-devel to CC]
> 
> On 17 Jan 2015, at 15:19, Gabriel Scherer <gabriel.scherer at gmail.com> wrote:
> > 
> > There is an excellent piece at LWN.net (do consider subscribing to
> > this source of quality technical news) about a recent discussion in
> > the Python community on how to "secure" their package manager
> >  http://lwn.net/SubscriberLink/629426/bf933f7acea8466c/
> > 
> > The article discusses in particular a library called TUF (The Update
> > Framework) that aims to help solve the problem in a
> > package-manager-agnostic way.
> >  http://theupdateframework.com/
> > (this page has some other interesting links, eg. to a similar
> > discussion in the Ruby community about RubyGems)
> > 
> > Is there a reference point to a discussion of the security aspects of
> > the OPAM package manager? What I found so far is this 2013 issue by
> > Edwin Török on signing packages:
> >  https://github.com/ocaml/opam/issues/423
> > 
> > As far as I know, the current status is that OPAM checks downloaded
> > packages against the checksum in opam-repository, so it protects
> > against an attacker changing upstream releases, assuming the
> > opam-repository remains trusted and there is no man-in-the-middle
> > (MITM) attack when the user downloads the metadata -- afaik it uses
> > only HTTP currently.
> 
> This is certainly something that needs to go on the roadmap sooner
> rather than later, and issue #423 is still the place to record
> your opinions.
> 
> Having a signify-like model to let an OPAM mirroring script sign
> distfiles would be a good first step, since the complexities of
> managing a per-contributor signing infrastructure would be quite
> significantly more work.
> 
> Note that the OPAM remote is HTTPS by default since OPAM 1.1.
> 
> -anil
> 
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>