[opam-devel] OPAM 1.3 roadmap

[Louis Gesbert]

Yes, that's the kind of thing I had in mind. Incidentally, the Makefile joke happened to me while in school, a few days before a project was due -- never forgot the lesson :) (I removed the unused DOC variable definition. Except `make clean` had `rm -rf $(DOC)/`. Notice the last char...)

This is more related to protecting against mistakes than protecting against malice, like repo signing is, but both are important. The point being that _if_ a malicious package makes it through, it can just do the bad stuff at runtime once it's installed rather than do it during compilation or installation. And that's actually easier to hide from the repo maintainers. Therefore, not having a completely secure sandboxing solution is not a blocker if one isn't easily available.

> 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).

Sounds cool, I'll check that out. I am also aware of http://proot.me/

> - Roberto Di Cosmo, 23/02/2015 09:50 -
> 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
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel