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 -- Roberto Di Cosmo ------------------------------------------------------------------ Professeur En delegation a l'INRIA PPS E-mail: [email protected] Universite Paris Diderot WWW : http://www.dicosmo.org Case 7014 Tel : ++33-(0)1-57 27 92 20 5, Rue Thomas Mann F-75205 Paris Cedex 13 Identica: http://identi.ca/rdicosmo FRANCE. Twitter: http://twitter.com/rdicosmo ------------------------------------------------------------------ Attachments: MIME accepted, Word deprecated http://www.gnu.org/philosophy/no-word-attachments.html ------------------------------------------------------------------ Office location: Bureau 3020 (3rd floor) Batiment Sophie Germain Avenue de France Metro Bibliotheque Francois Mitterrand, ligne 14/RER C ----------------------------------------------------------------- GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
