Yes, that's exactly my thought actually, seems I didn't make myself clear : for the sandboxing, I meant the `install` instructions should be restricted to the switch prefix rather than to the OPAM root.
For the git tracking, it seems more consistent to do it per-switch at first glance, but there may be some advantages in doing it at the opam root. > - Anil Madhavapeddy, 27/02/2015 09:34 - > I'd quite like sandboxing to be done at the individual command invocation > level, with a set of valid-to-write directory prefixes passed through to the > `sandbox` binary. > > In particular, this implies that there would only be a couple of directories > passed at the build phase (the `/tmp` and `~/.opam/<...>/build` ones), with > the installation prefixes appended in the subsequent package install phase. > > -anil > > > On 27 Feb 2015, at 01:37, Louis Gesbert <[email protected]> wrote: > > > > Just a quick remark: I would rather have the sandboxing done at the switch > > prefix level rather than at the OPAMROOT level: that's where package > > scripts should be restricted, and, in particular for the git-tracking > > feature, you probably don't want to rollback your `opam update`s, and > > tracking installs for each switch sounds more friendly. > > > > This would probably imply it's done within OPAM. Hm, and you don't get > > cross-switch sharing to save git space. > > > >> - Anil Madhavapeddy, 24/02/2015 16:22 - > >> Hi Roberto, Simon, > >> > >> Sandboxing mechanisms have come along quite a bit in the last few years. > >> It's important to separate the two threat models that we want, since their > >> use can be quite intrusive if made mandatory. I see two modes of > >> operation: > >> > >> - A mandatory sandbox in CI testing, where we use it to check that the > >> package isn't violating obvious policies such as network downloads > >> from within the package, or writing outside of ~/.opam or /tmp. > >> > >> - Optional sandbox for day-to-day use by end users. This will catch > >> even malicious behaviours, but imposes a rather heavy support burden. > >> > >> In terms of how to sandbox applications, I know of: > >> > >> - OpenBSD: I use the built-in systrace system call permissions subsystem > >> already with OPAM. I've uploaded my local policy to GitHub at: > >> https://gist.github.com/avsm/8293aa52c6cee772a9cb > >> This policy is used by "systrace opam install foo" and pulls up an > >> interactive dialog if an application attempts to write outside of > >> either ~/.opam or /tmp. > >> See: http://www.openbsd.org/cgi-bin/man.cgi?query=systrace > >> or: http://www.citi.umich.edu/u/provos/systrace/ > >> paper: http://www.citi.umich.edu/u/provos/papers/systrace.pdf > >> > >> - FreeBSD: the latest versions have the Capsicum capability system > >> integrated, and the Casper system daemon that grants common operations > >> is also being worked on upstream (e.g. for name resolution) > >> See: https://www.cl.cam.ac.uk/research/security/capsicum/ > >> > >> - Linux: As always with Linux, there are a myriad of possible solutions. > >> I'd discourage the use of LD_PRELOAD based solutions since they don't > >> work in several situations reliably (most obviously with static binaries). > >> The fakeroot-ng project uses ptrace instead, which is more reliable. > >> > >> However, the primary thing we want is to only let the package only > >> write into ~/.opam, and so the mount namespace feature (see CLONE_NEWNS) > >> may be sufficient for our needs -- a lightweight filesystem container, > >> in effect. David Sheets has done some investigation into this for > >> another project we're working on. > >> > >> - Windows: various, Sandboxie is one solution, but the underlying > >> mechanism is the Windows Integrity Mechanism that was introduced in > >> Vista: https://msdn.microsoft.com/en-us/library/bb625964.aspx > >> This lets applications drop privileges, and is used by the Chrome > >> sandbox (in general, following what Chrome does for sandboxing is a > >> good idea, since their needs are a superset of ours). > >> > >> - MacOS X: The App Sandbox requires code signing, but does almost > >> exactly what we need: it gives each app/user a unique directory > >> into which they can write files. All we should need to do is to > >> set OPAMROOT to that directory, and everything should just work. > >> In practise, this requires some investigation into how the App > >> signing infrastructure works, since I've only seen it done for > >> bundles and not for CLI tools. > >> > >> This is a quick off-the-top-of-my-head survey, but I think it's viable > >> and useful for us to build an `opam sandbox` in the same style as > >> `opam depext` that attempts to invoke a relevant sandboxing mechanism > >> depending on the OS. In the longer term, this will really serve us > >> well as the package database grows. > >> > >> I'm less sure about the viability of recording installed files > >> strictly -- I view thatas an advisory rather than enforcement-based > >> mechanism. The reason I like the "make ~/.opam a git store" is that > >> its possible for applications to write directly into the store as they > >> do right now, but still let us track changes precisely. In fact, if > >> we forbid subshells from writing into `~/.opam/.git`, this would be > >> a production grade solution that also offers instant-rollback in case > >> of compilation errors (no more waiting for a full recompilation of > >> the original dependencies!). > >> > >> cheers, > >> Anil > >> > >>> On 21 Feb 2015, at 09:16, Roberto Di Cosmo <[email protected]> wrote: > >>> > >>> Anil, Simon, can you provide more details on the sandboxing mechanisms > >>> you know of? > >>> > >>> We looked into all this for Mancoosi years ago; the most complete tool > >>> out there was installwatch (now checkinstall) that hijacks filesystem > >>> modifying > >>> commands using the standard LD_PRELOAD trick and a wrapper for system > >>> calls. > >>> Checkinstall does not alter user priviledges, though, so one sometimes > >>> needed > >>> a combination of fakeroot (that only alter user priviledges) with it. > >>> > >>> The best approach I know of was described in a Master thesis from ... > >>> Cambridge > >>> :-) It was under the supervision of Peter Sewell, and used the ptrace > >>> mechanism > >>> instead of the LD_PRELOAD trick, because LD_PRELOAD is blind to statically > >>> compiled binaries that have system calls hardcoded, while ptrace gets > >>> them all. > >>> > >>> The dissertation is still available today here > >>> http://robot101.net/files/diss.ps.gz > >>> and contains a very nice discussion of the issues related to monitoring > >>> and > >>> rolling back file system changes performed by a command in the Linux > >>> system. > >>> The source code is also available here > >>> http://robot101.net/files/trace.tar.gz > >>> and one can get in touch with Robert Mcqueen that will be delighted to > >>> see his > >>> work being used. > >>> > >>> Since all this is almost 10 years old, I suppose many exciting new ideas, > >>> tools > >>> and approaches surfaced in the meantime, and I'd really like to know more. > >>> > >>> Cheers > >>> > >>> -- > >>> Roberto > >>> > >>> On Sat, Feb 21, 2015 at 09:37:07AM +0100, Simon Cruanes wrote: > >>>> Sandboxing the build would also be a big security improvement. I think > >>>> cabal > >>>> now does it, and signing packages doesn't protect against malicious or > >>>> buggy > >>>> packages (see: bumblebee's uninstall target). That also goes hand in > >>>> hand with > >>>> file tracking. I don't know how difficult it is, though. > >>>> > >>>> Cheers! > >>>> > >>>> Le 21 février 2015 05:01:56 UTC+01:00, Louis Gesbert > >>>> <[email protected]> a écrit : > >>>> > >>>> With 1.2.1 almost out of the door, time has come to review the roadmap > >>>> discussed back in December and choose where we'll be going for 1.3. > >>>> Original mail attached for reference. > >>>> > >>>> > >>>> The topic that is burning hot at the moment is, specially after the > >>>> Debian Haskell build host has been compromised, security: we have no > >>>> signing at all at the moment, and we need to improve on this before it > >>>> becomes a problem. TUF [1] has devised a sane amount of rules for > >>>> repository management and signing that should make it easier to get it > >>>> right in OPAM. Hannes has mentionned writing an OCaml implementation for > >>>> TUF, which could get very helpful. > >>>> > >>>> > >>>> Also of importance is Windows support. It should at least be > >>>> straighforward and documented to get a basic Cygwin setup working. That > >>>> goes with adding automated tests (appveyor can now be added in Github > >>>> alongside Travis). Related is cleaning up external command usage (even > >>>> if not really justified by a Windows > >>>> port only, as David Allsopp pointed out) -- replacing curl calls by > >>>> cohttp, use ocaml-fileutils... > >>>> > >>>> > >>>> These are the other main features, that'll probably take more time if > >>>> we are to focus eg. on security: > >>>> > >>>> * a plugin mechanism with plugins for example for OCaml (for better > >>>> agnosticity), external dependency handling [2], documentation > >>>> generation... > >>>> > >>>> * a 'provides:' field in OPAM files [3]. This is a loose requirement > >>>> if we want to switch the repository to have OCaml itself in a package > >>>> (which is already possible, but the system compiler may yet be an issue). > >>>> > >>>> * More flexible switch handling (multi-switch packages, per-switch > >>>> remotes, layered switches for cross-compilation...) > >>>> > >>>> * Tracking of files installed by packages. While unrelated to repo > >>>> signing, this might have some security implications, so we might want to > >>>> bring it in. > >>>> > >>>> * With file tracking, generating a binary repo (with some limitations) > >>>> could be quite > >>>> straight-forward. > >>>> > >>>> > >>>> Which of these do you think is most important ? Have I forgotten > >>>> anything ? > >>>> > >>>> Cheers, > >>>> Louis > >>>> > >>>> > >>>> [1] http://theupdateframework.com/ > >>>> [2] > >>>> https://github.com/ocaml/opam/blob/master/doc/design/depexts-plugins > >>>> [3] https://github.com/ocaml/opam/blob/master/doc/design/provides.md > >>>> > >>>> message suivi > >>>> > >>>> De : Louis Gesbert > >>>> À : [email protected] > >>>> Envoyé : Wed Dec 17 11:07:40 UTC+01:00 2014 > >>>> Objet : [opam-devel] OPAM Roadmap -- what next ? > >>>> > >>>> Hi all, > >>>> > >>>> > >>>> > >>>> with some lag after the 1.2 release, I'd like to open some space for a > >>>> collective discussion of the priorities for where the energies should > >>>> go > >>>> next. We have mainly 3 directions for improvements: first, portability, > >>>> with the main goal of a Windows version. Second, agnosticity, with the > >>>> goal > >>>> to make OPAM more generic, and try and open it to users outside of the > >>>> OCaml community (wouldn't OPAM for Haskell be fun ?). Third, there are > >>>> always lots of features and improvements that have been asked for, and > >>>> would improve the experience of current users. > >>>> > >>>> > >>>> > >>>> So here is a summary of what I've gathered. Feel free to add your own. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> ## Portability > >>>> > >>>> > >>>> > >>>> - **Rewrite parallel command engine.** / done. > >>>> > >>>> > >>>> > >>>> - **Native system manipulation (cp, rm, curl...).** > >>>> > >>>> These are mostly done through calls to the shell or external programs. > >>>> It's > >>>> > >>>> not very pretty but quite pragmatic actually... until we want to run on > >>>> > >>>> Windows without Cygwin. Anyway, this wouldn't be the end of portability > >>>> > >>>> issues. > >>>> > >>>> > >>>> > >>>> - **Windows support.** > >>>> > >>>> for OPAM itself to begin with. This should be pretty close. > >>>> > >>>> > >>>> > >>>> - **Packages on Windows.** > >>>> > >>>> Locate common issues and attempt to find generic fixes. > >>>> > >>>> > >>>> > >>>> - Allow **direct use of more solvers** or solver servers. > >>>> > >>>> > >>>> > >>>> - **Support cross-compilation** > >>>> > >>>> This is quite an open issue at the moment. > >>>> > >>>> > >>>> > >>>> ## Agnosticity > >>>> > >>>> > >>>> > >>>> - **Isolate OCaml-specific stuff.** > >>>> > >>>> E.g. specific opam-file variables. See ocaml-specific.md > >>>> > >>>> > >>>> > >>>> - **Separate as plugins** > >>>> > >>>> To open the gate to OPAM without these plugins, or with other ones > >>>> > >>>> > >>>> > >>>> - **Compilers as packages.** > >>>> > >>>> This should mostly work now, but needs some tests and strengthening. > >>>> The > >>>> main > >>>> > >>>> thing still to do is to handle the system compiler changes properly ; > >>>> that > >>>> > >>>> part should be made more generic anyway (see discussion on hooks) > >>>> > >>>> > >>>> > >>>> ## Features > >>>> > >>>> > >>>> > >>>> - A **provides** field. Generally useful, but particulary so with > >>>> > >>>> compilers-as-packages > >>>> > >>>> > >>>> > >>>> - Releasing the **"features" field** for easier package configuration > >>>> > >>>> > >>>> > >>>> - **Track installed files** > >>>> > >>>> > >>>> > >>>> - **Improve security**: just checking md5s is quite light ; package > >>>> scripts > >>>> can > >>>> > >>>> write anywhere > >>>> > >>>> > >>>> > >>>> - **OS-specific handling of dependencies** (eg dependencies on packages > >>>> from the > >>>> > >>>> OS) with plugins (#1519) > >>>> > >>>> > >>>> > >>>> - Specify and implement **hooks** > >>>> > >>>> > >>>> > >>>> - Find a nicer way to **share dev repos** / undoable "pinning sources" > >>>> > >>>> > >>>> > >>>> - **Per-switch remotes** > >>>> > >>>> > >>>> > >>>> - **Multi-switch packages** > >>>> > >>>> > >>>> > >>>> - Support for (automatic generation of) **binary packages** > >>>> > >>>> > >>>> > >>>> - Nicer **ocamlfind interaction** > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Cheers, > >>>> > >>>> Louis Gesbert > >>>> > >>>> > >>>> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > >>>> > >>>> opam-devel mailing list > >>>> [email protected] > >>>> http://lists.ocaml.org/listinfo/opam-devel > >>>> > >>>> > >>>> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > >>>> > >>>> opam-devel mailing list > >>>> [email protected] > >>>> http://lists.ocaml.org/listinfo/opam-devel > >>>> > >>>> > >>>> -- > >>>> Simon > >>> > >>>> _______________________________________________ > >>>> opam-devel mailing list > >>>> [email protected] > >>>> http://lists.ocaml.org/listinfo/opam-devel > >>> > >>> > >> > > _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
