opam: Sandboxing is not working on your platform void

[Sqvid]

Is this a new report?

Yes

System Info

Void 6.18.44_1 x86_64 AuthenticAMD uptodate rrrr

Package(s) Affected

opam-2.5.2_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

Some issues exist for other platforms like ubuntu but they seem to have been closed a while ago:
ocaml/opam#5077
ocaml/opam#6820
ocaml/opam#4368

Expected behaviour

I have opam, bwrap, and apparmor installed. However, sandboxing seems broken despite setting up each tool as instructed in the Void Handbook, and OPAM Docs.

I would expect opam to succeed.

Actual behaviour

opam says sandboxing is not supported. Disabling sandboxing works but comes with obvious drawbacks.

Steps to reproduce

$ xbps-install -S opam bubblewrap apparmor runit-void-apparmor
(successful)

$ aa-enabled
Yes

$ cat /etc/apparmor.d/opam
# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi <abi/4.0>,
include <tunables/global>

profile opam /usr/bin/opam flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/opam>
}

$ opam init
No configuration file found, using built-in defaults.
Checking for available remotes: rsync and local, git.
  - you won't be able to use mercurial repositories unless you install the hg command on your system.
  - you won't be able to use darcs repositories unless you install the darcs command on your system.

[ERROR] Sandboxing is not working on your platform void:
        "~/.opam/opam-init/hooks/sandbox.sh build sh -c echo SUCCESS | tee check-write" exited with code 1
Do you want to disable it?  Note that this will result in less secure package builds, so please ensure that you have some other isolation mechanisms
in place (such as running within a container or virtual machine). [y/N] 

[Sqvid]

This is possibly fixed by ocaml/opam#6823, though I installed via xbps and not install.sh

[Sqvid]

@kit-ty-kate I see you maintain opam and have bumped the package previously in Void as well. Any wisdom you can share that would help me debug this would be highly appreciated. Thank you so much!

[kit-ty-kate]

This could indeed be ocaml/opam#5968. Where does void install opam? Is that /usr/bin/opam? If it's not then you need to add an apparmor profile similar to how our install script does it.

If it is though there might be something else at play. What does bash -x ~/.opam/opam-init/hooks/sandbox.sh build echo say?

[kit-ty-kate]

I just tried it in docker and i think i know what's happening: opam is installed in /usr/bin/opam so this should be fine. However the opam package in void doesn't require bash and coreutils which are both required to make the sandbox script work sadly (e.g. busybox's realpath is too barebone, posix shell lack proper array support to make dealing with arguments safe, …)

I think they should probably be added as a runtime dependency on the opam package

[kit-ty-kate]

I've opened ocaml/opam#7081 to help debug this kind of issues faster in the future. In the meantime you can see the output of commands by calling opam with -vv (verbose level 2)

[Sqvid]

Thank you so much for taking the time to help me! Adding some stderr would be super helpful to debug this stuff in the future.

This could indeed be ocaml/opam#5968. Where does void install opam? Is that /usr/bin/opam? If it's not then you need to add an apparmor profile similar to how our install script does it.

Indeed

$ which opam
/usr/bin/opam

However the opam package in void doesn't require bash and coreutils which are both required to make the sandbox script work sadly (e.g. busybox's realpath is too barebone, posix shell lack proper array support to make dealing with arguments safe, …)

Hmm this makes sense for a container but I am running it outside of docker and therefore have bash and coreutils installed

$ xbps-query --list-pkgs | grep -E 'bash|coreutils' 
ii bash-5.3_2                              GNU Bourne Again Shell
ii coreutils-9.4_3                         GNU core utilities
ii dash-0.5.12_3                           POSIX-compliant Unix shell, much smaller than GNU bash

Is there something I am missing to make these visible to sandbox.sh?

[Sqvid]

I tried to construct a xbps-src template for the 2.6.0~alpha1 release with bash and coreutils as runtime dependencies.

Here's the diff to the template file

diff --git a/srcpkgs/opam/template b/srcpkgs/opam/template
index 82dc53690da..8cd909774cb 100644
--- a/srcpkgs/opam/template
+++ b/srcpkgs/opam/template
@@ -1,20 +1,20 @@
 # Template file for 'opam'
 pkgname=opam
-version=2.5.2
+version=2.6.0
 revision=1
 build_style=gnu-configure
 configure_args="--docdir=/usr/share/doc/${pkgname} --with-vendored-deps --with-mccs"
 make_build_args="all"
 make_check_target="tests"
-depends="bubblewrap curl unzip tar"
-makedepends="${depends} ncurses-devel ocaml ocaml-findlib"
-checkdepends="${depends} git rsync"
+depends="bubblewrap curl unzip tar bash coreutils"
+makedepends="tar unzip ncurses-devel ocaml ocaml-findlib"
+checkdepends="git rsync"
 short_desc="OCaml package manager"
 maintainer="Leah Neukirchen <leah@vuxu.org>"
 license="LGPL-2.1-only WITH OCaml-LGPL-linking-exception"
 homepage="https://opam.ocaml.org/"
-distfiles="https://github.com/ocaml/opam/releases/download/${version}/opam-full-${version}.tar.gz"
-checksum=b3623809567f19ed6b5d679b8c7bbc0bdec9418bff4a875ff0799d446d8555c3
+distfiles="https://github.com/ocaml/opam/releases/download/${version}-alpha1/opam-full-${version}-alpha1.tar.gz"
+checksum=c2271205eaaefe80ff5bcd317e320d6106afa1d6c40038da6389b2f12de14df7
 nocross=yes
 disable_parallel_build=yes
 make_check=ci-skip # uses bwrap

You can see that they have been added as runtime dependencies after installing

$ xbps-query opam
...
run_depends:
        bubblewrap>=0
        curl>=0
        unzip>=0
        tar>=0
        bash>=0
        coreutils>=0
        glibc>=2.41_1
        libgcc>=4.4.0_1
        libstdc++>=4.4.0_1
...

Unfortunately, the problem persists

$ which opam
/usr/bin/opam

$ opam --version
2.6.0~alpha1

$ opam init          
No configuration file found, using built-in defaults.
Checking for available remotes: rsync and local, git.
  - you won't be able to use mercurial repositories unless you install the hg command on your system.
  - you won't be able to use darcs repositories unless you install the darcs command on your system.

[ERROR] Sandboxing is not working on your platform void:
        "~/.opam/opam-init/hooks/sandbox.sh build sh -c echo SUCCESS | tee check-write" exited with code 1
Do you want to disable it?  Note that this will result in less secure package builds, so please ensure that you have some other isolation mechanisms
in place (such as running within a container or virtual machine). [y/N] 

Hopefully some of this is useful as early QA testing for the alpha release 😅

[Duncaen]

There is currently a bug where when you boot with apparmor set to complain in /etc/default/apparmor, the init scripts will force the "unconfined" apparmor profile into complain mode, which then breaks bwrap because of disconnected paths. Could that be the same issue?

[Duncaen]

Seems to work fine here with apparmor set to enforce mode:

/tmp% opam init
No configuration file found, using built-in defaults.
Checking for available remotes: rsync and local, git, mercurial, darcs. Perfect!

<><> Fetching repository information ><><><><><><><><><><><><><><><><><><><><><>
[default] Initialised

<><> Required setup - please read <><><><><><><><><><><><><><><><><><><><><><><>

  In normal operation, opam only alters files within ~/.opam.

  However, to best integrate with your system, some environment variables
  should be set. If you allow it to, this initialisation step will update
  your zsh configuration by adding the following line to ~/.zshrc:

    [[ ! -r '/home/duncan/.opam/opam-init/init.zsh' ]] || source '/home/duncan/.opam/opam-init/init.zsh' > /dev/null 2> /dev/null

  Otherwise, every time you want to access your opam installation, you will
  need to run:

    eval $(opam env)

  You can always re-run this setup with 'opam init' later.

Do you want opam to configure zsh?
  1. Yes, update ~/.zshrc
  2. Yes, but don't setup any hooks. You'll have to run eval $(opam env) whenever you change your current 'opam switch'
  3. Select a different shell
  4. Specify another config file to update instead
> 5. No, I'll remember to run eval $(opam env) when I need opam

[1/2/3/4/5] 5

<><> Creating initial switch 'default' (invariant ["ocaml" {>= "4.05.0"}] - initially with ocaml-base-compiler)

<><> Installing new switch packages <><><><><><><><><><><><><><><><><><><><><><>
Switch invariant: ["ocaml" {>= "4.05.0"}]
[NOTE] External dependency handling not supported for OS family 'void'.
       You can disable this check using 'opam option --global depext=false'

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
∗ installed base-bigarray.base
∗ installed base-threads.base
∗ installed base-unix.base
∗ installed compiler-cloning.enabled
∗ installed ocaml-options-vanilla.1
⬇ retrieved ocaml.5.5.0  (https://opam.ocaml.org/cache)
⬇ retrieved ocaml-compiler.5.5.0  (https://opam.ocaml.org/cache)
∗ installed ocaml-compiler.5.5.0
∗ installed ocaml-base-compiler.5.5.0
∗ installed ocaml.5.5.0
∗ installed base-domains.base
∗ installed base-effects.base
∗ installed base-nnp.base
Done.

<><> ocaml-compiler.5.5.0 installed successfully ><><><><><><><><><><><><><><><>
=> This switch had to be compiled from sources, but future switches with the 🐌
   same compiler version and configuration should assemble instantly.
# To update the current shell environment, run: eval $(opam env --switch=default)

[Sqvid]

Seems to work fine here with apparmor set to enforce mode:

Thanks @Duncaen you seemed to have solved it!
I changed /etc/default/apparmor to

7c7
< APPARMOR=complain
---
> APPARMOR=enforce

There is currently a bug where when you boot with apparmor set to complain in /etc/default/apparmor, the init scripts will force the "unconfined" apparmor profile into complain mode, which then breaks bwrap because of disconnected paths.

What is the recommended solution here? It looks like the enforce default is more strict than complain so could changing it to fix the issue inadvertently break other software? Or would it be wiser to leave the default as is and wait for a patch/fix to the apparmor-bwrap issue?

[Duncaen]

When the profile is forced into complain mode instead of unconfined then it fails, but if its in enforce mode, the init scripts do not force it into complain mode and it stays unconfined.

The other issue that makes it actually fail in complain mode is in bubblewrap (containers/bubblewrap#769) where it uses a file descriptor not associated with the current mount namespace. In complain mode apparmor tries to reconstruct paths from file descriptors to later match them against apparmor rules.

This PR #61695 will "fix" the part where the profile is forced into complain mode, by basically just removing that mode and defaulting to enforce, because there is no better way to set profiles into complain mode without forcing unconfined into it.

[Duncaen]

Merged #61695, so it should be fixed.