<html><head></head><body>The one I'm most familiar with is fakeroot, used by archlinux for building its packages; it's relevant because the average user (me) can install unsupported software from AUR (a large repository of user-contributed, unsupported packages). Fakeroot is used during the compilation of such packages, before a proper archive is built (one that the distribution package manager, pacman, can use to install/uninstall). Apparently fakeroot emulates a filesystem in a sub-directory and makes believe the untrusted software that is being compiled that it has root privileges to write in the filesystem.<br>
<br>
It is probably impossible to do that in a portable way across all OSes, so I think the first step is building in a temporary directory. For Windows support, using shell commands is discouraged (as far as I understood) so opam could provide its own file manipulation directives that would respect the boundaries of the temporary directory.<br><br><div class="gmail_quote">Le 21 février 2015 10:16:03 UTC+01:00, Roberto Di Cosmo <roberto@dicosmo.org> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Anil, Simon, can you provide more details on the sandboxing mechanisms you know of?<br /><br />We looked into all this for Mancoosi years ago; the most complete tool<br />out there was installwatch (now checkinstall) that hijacks filesystem modifying<br />commands using the standard LD_PRELOAD trick and a wrapper for system calls.<br />Checkinstall does not alter user priviledges, though, so one sometimes needed<br />a combination of fakeroot (that only alter user priviledges) with it.<br /><br />The best approach I know of was described in a Master thesis from ... Cambridge<br />:-) It was under the supervision of Peter Sewell, and used the ptrace mechanism<br />instead of the LD_PRELOAD trick, because LD_PRELOAD is blind to statically<br />compiled binaries that have system calls hardcoded, while ptrace gets them all.<br /><br />The dissertation is still available today here <a
href="http://robot101.net/files/diss.ps.gz">http://robot101.net/files/diss.ps.gz</a><br />and contains a very nice discussion of the issues related to monitoring and<br />rolling back file system changes performed by a command in the Linux system.<br />The source code is also available here <a href="http://robot101.net/files/trace.tar.gz">http://robot101.net/files/trace.tar.gz</a><br />and one can get in touch with Robert Mcqueen that will be delighted to see his<br />work being used.<br /><br />Since all this is almost 10 years old, I suppose many exciting new ideas, tools<br />and approaches surfaced in the meantime, and I'd really like to know more.<br /><br />Cheers<br /><br />--<br />Roberto<br /><br />On Sat, Feb 21, 2015 at 09:37:07AM +0100, Simon Cruanes wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Sandboxing the build would also be a big security improvement. I think cabal<br /> now does
it, and signing packages doesn't protect against malicious or buggy<br /> packages (see: bumblebee's uninstall target). That also goes hand in hand with<br /> file tracking. I don't know how difficult it is, though.<br /> <br /> Cheers!<br /> <br /> Le 21 février 2015 05:01:56 UTC+01:00, Louis Gesbert<br /> <louis.gesbert@ocamlpro.com> a écrit :<br /> <br />     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.<br /> <br /> <br />     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.<br /> <br /> <br />     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<br />     port only, as David Allsopp pointed out) -- replacing curl calls by cohttp, use ocaml-fileutils...<br /> <br /> <br />     These are the other main features, that'll probably take more time if we are to focus eg. on security:<br /> <br />     * a plugin mechanism with plugins for example for OCaml (for better agnosticity), external dependency handling [2], documentation generation...<br /> <br />     * 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).<br />
<br />     * More flexible switch handling (multi-switch packages, per-switch remotes, layered switches for cross-compilation...)<br /> <br />     * 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.<br /> <br />     * With file tracking, generating a binary repo (with some limitations) could be quite<br />     straight-forward.<br /> <br /> <br />     Which of these do you think is most important ? Have I forgotten anything ?<br /> <br />     Cheers,<br />     Louis<br /> <br /> <br />     [1] <a href="http://theupdateframework.com">http://theupdateframework.com</a>/<br />     [2] <a href="https://github.com/ocaml/opam/blob/master/doc/design/depexts-plugins">https://github.com/ocaml/opam/blob/master/doc/design/depexts-plugins</a><br />     [3] <a
href="https://github.com/ocaml/opam/blob/master/doc/design/provides.md">https://github.com/ocaml/opam/blob/master/doc/design/provides.md</a><br /> <br />     message suivi<br /> <br />       De :   Louis Gesbert<br />       À :    opam-devel@lists.ocaml.org<br />     Envoyé : Wed Dec 17 11:07:40 UTC+01:00 2014<br />     Objet :  [opam-devel] OPAM Roadmap -- what next ?<br /> <br />     Hi all,<br /> <br />      <br /> <br />     with some lag after the 1.2 release, I'd like to open some space for a<br />     collective discussion of the priorities for where the energies should go<br />     next. We have mainly 3 directions for improvements: first, portability,<br />     with the main goal of a Windows version. Second, agnosticity, with the goal<br />     to make OPAM more generic, and try and open it to users outside of the<br />     OCaml community (wouldn't OPAM for Haskell be fun ?). Third, there are<br />     always lots of features and improvements that have been asked
for, and<br />     would improve the experience of current users.<br /> <br />      <br /> <br />     So here is a summary of what I've gathered. Feel free to add your own.<br /> <br />      <br /> <br />      <br /> <br />      <br /> <br />     ## Portability<br /> <br />      <br /> <br />     - **Rewrite parallel command engine.** / done.<br /> <br />      <br /> <br />     - **Native system manipulation (cp, rm, curl...).**<br /> <br />     These are mostly done through calls to the shell or external programs. It's<br /> <br />     not very pretty but quite pragmatic actually... until we want to run on<br /> <br />     Windows without Cygwin. Anyway, this wouldn't be the end of portability<br /> <br />     issues.<br /> <br />      <br /> <br />     - **Windows support.**<br /> <br />     for OPAM itself to begin with. This should be pretty close.<br /> <br />      <br /> <br />     - **Packages on Windows.**<br /> <br />     Locate common issues and attempt to find generic
fixes.<br /> <br />      <br /> <br />     - Allow **direct use of more solvers** or solver servers.<br /> <br />      <br /> <br />     - **Support cross-compilation**<br /> <br />     This is quite an open issue at the moment.<br /> <br />      <br /> <br />     ## Agnosticity<br /> <br />      <br /> <br />     - **Isolate OCaml-specific stuff.**<br /> <br />     E.g. specific opam-file variables. See <a href="http://ocaml-specific.md">ocaml-specific.md</a><br /> <br />      <br /> <br />     - **Separate as plugins**<br /> <br />     To open the gate to OPAM without these plugins, or with other ones<br /> <br />      <br /> <br />     - **Compilers as packages.**<br /> <br />     This should mostly work now, but needs some tests and strengthening. The<br />     main<br /> <br />     thing still to do is to handle the system compiler changes properly ; that<br /> <br />     part should be made more generic anyway (see discussion on hooks)<br /> <br />      <br /> <br />     ##
Features<br /> <br />      <br /> <br />     - A **provides** field. Generally useful, but particulary so with<br /> <br />     compilers-as-packages<br /> <br />      <br /> <br />     - Releasing the **"features" field** for easier package configuration<br /> <br />      <br /> <br />     - **Track installed files**<br /> <br />      <br /> <br />     - **Improve security**: just checking md5s is quite light ; package scripts<br />     can<br /> <br />     write anywhere<br /> <br />      <br /> <br />     - **OS-specific handling of dependencies** (eg dependencies on packages<br />     from the<br /> <br />     OS) with plugins (#1519)<br /> <br />      <br /> <br />     - Specify and implement **hooks**<br /> <br />      <br /> <br />     - Find a nicer way to **share dev repos** / undoable "pinning sources"<br /> <br />      <br /> <br />     - **Per-switch remotes**<br /> <br />      <br /> <br />     - **Multi-switch packages**<br /> <br />      <br /> <br />     - Support
for (automatic generation of) **binary packages**<br /> <br />      <br /> <br />     - Nicer **ocamlfind interaction**<br /> <br />      <br /> <br />      <br /> <br />      <br /> <br />     Cheers,<br /> <br />     Louis Gesbert<br /> <br />     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━<br /> <br />     opam-devel mailing list<br />     opam-devel@lists.ocaml.org<br />     <a href="http://lists.ocaml.org/listinfo/opam-devel">http://lists.ocaml.org/listinfo/opam-devel</a><br /> <br />     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━<br /> <br />     opam-devel mailing list<br />     opam-devel@lists.ocaml.org<br />     <a
href="http://lists.ocaml.org/listinfo/opam-devel">http://lists.ocaml.org/listinfo/opam-devel</a><br /> <br /> <br /> --<br /> Simon<br /></blockquote><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><hr /><br /> opam-devel mailing list<br /> opam-devel@lists.ocaml.org<br /> <a href="http://lists.ocaml.org/listinfo/opam-devel">http://lists.ocaml.org/listinfo/opam-devel</a><br /></blockquote><br /></pre></blockquote></div><br>
-- <br>
Simon</body></html>