[opam-devel] OPAM 1.3 roadmap

[Roberto Di Cosmo]

On Mon, Feb 23, 2015 at 10:07:58AM +0900, Louis Gesbert wrote:
> That's starting to sound fairly consistent:
> 
> # Secure OPAM itself a bit:
> 
>   * Sandbox the build step: not sure how to do it, but it should be without network access, and only allowed to write to its build dir.

This is really *not easy* in the current state of affairs

 -> opam calls whatever command is declared in the build:/install: fields

 -> this command can do whatever it wants; a sloppy Makefile might very well end
    up removing all the user-writeable files on a machine; think of something like

    PREFIX=$(HOME)/$(MYNICELOCALVAR)   # ooops ... using a var defined only on the dev machine!

    install:
        rm -rf $(PREFIX) # clean up dest dir on the dev machine; rm -rf $(HOME) everywhere else!
        ....

 -> it's easy to pass through the integration test on opam-repository too: if
    somebody really wants to make bad jokes, one can simply check the
    environment to be nice when going through Travis, and wreak havoc elsewhere

In the GNU/Linux distribution world, we face a similar challenge, with install
scripts being on top run as root; the very stringent QA process enforced
by these communities mitigates the problem quite a bit, of course, but
it is still there and s*it happens.

That's why I was asking for the characteristics of the sandboxing techniques we
known. As with security, "sandbox" is a term easy to use, but difficult to
achieve.

My best bet is _really_ the ptrace approach followed by Mcqueen in
http://robot101.net/files/trace.tar.gz as it allows to monitor _all_ file
access even by statically linked binaries, and is able to make a backup
copy of modified files (to restore them, if something goes wrong).

What I do not know is whether something similar is available for *BSD,
and even less for Windows.

And of course, this would make yet another external dependency, but there
is no free lunch.

Cheers

--
Roberto