opam broken on ubuntu 24.04 (bwrap: operation not permitted)

[dlesbre]

I've recently upgraded my computer from kubuntu 23.10 to kubuntu 24.04. This lead to errors with opam. Specifically, opam upgrade failed at trying to build the first package (dune.3.15.2), and opam switch create 4.14.1 also failed with the same error message:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Doing some digging, it seems to be related to ubuntu deciding to restrict unprivileged user namespaces https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces. I found a fix, detailed here: https://etbe.coker.com.au/2024/04/24/ubuntu-24-04-bubblewrap/ which got opam working again.

Config:

<include here the output of `opam config report`, if applicable>
# opam config report
# opam-version         2.1.5 
# self-upgrade         no
# system               arch=x86_64 os=linux os-distribution=ubuntu os-version=24.04
# solver               builtin-mccs+glpk
# install-criteria     -removed,-count[avoid-version,changed],-count[version-lag,request],-count[version-lag,changed],-count[missing-depexts,changed],-changed
# upgrade-criteria     -removed,-count[avoid-version,changed],-count[version-lag,solution],-count[missing-depexts,changed],-new
# jobs                 19
# repositories         2 (http) (default repo at 76de4586)
# pinned               1 (rsync)
# current-switch       4.14
# ocaml:native         true
# ocaml:native-tools   true
# ocaml:native-dynlink true
# ocaml:stubsdir       /home/dorian/.opam/4.14/lib/ocaml/stublibs:/home/dorian/.opam/4.14/lib/ocaml
# ocaml:preinstalled   false
# ocaml:compiler       4.14.1

[cuihtlauac]

UPDATE (Oct 15, 2024):

Thanks to @gegarcia, there is a safer way to fix this (see discussion below).

1. Install package apparmor-profiles
2. sudo ln -s /usr/share/apparmor/extra-profiles/bwrap-userns-restrict /etc/apparmor.d/
3. [Optional] If not using Ubuntu packaged Opam:
   1. cp /etc/apparmor.d/opam /etc/apparmor.d/local.opam
   2. In /etc/apparmor.d/local.opam replace /usr/bin/opam by the output of which opam
4. systemctl reload apparmor

It's working for me.

ORIGINAL POST, OBSOLETE (June 6, 2024):

Thanks @dlesbre, I've experienced the same issue. Upgrade to 24.04, and then opam upgrade failure. Doing as suggested by @etbe worked. I'm copying his suggestion here:

To resolve that you could upgrade to SE Linux, but the other option is to create a file named /etc/apparmor.d/bwrap with the following contents:

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

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

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

Then run systemctl reload apparmor.

[samvv]

I can confirm that the solution posted by @cuihtlauac worked. Might be worthwhile to add it to the docs?

[hhugo]

same here

[kit-ty-kate]

Reading the upstream issue https://bugs.launchpad.net/wike/+bug/2046844?comments=all i'm really not sure what we should do and i'm bit lost honestly.
Adding a special message or a documentation telling the users to unconfine bubblewrap goes against the use of apparmor in the first place (to quote the dev): "Allowing Bubblewrap to do so would provide a loophole."

However looking at the apparmor sources, they seem to have a profile for opam already https://gitlab.com/apparmor/apparmor/-/commit/89a9f7673368e7d19802fd12ec3717a5477200e0 which was shipped in apparmor 4.0.0. Ubuntu 24.04 seems to have apparmor 4.0.1 so in theory it shouldn't be a problem anymore but if it is i'm not sure what was the point of the profile. Does anyone know anything about apparmor and are willing to work with upstream Ubuntu?

[etbe]

What you could do (and what I have done with SE Linux policy) is to have bubblewrap run with access to do such things and then transition back to another domain when it runs something.

Allowing a program to run another program with different levels of access potentially allows running another program with greater levels of access. But if we allow Bubblewrap to just do the things it needs to do (and not run random other programs with it's privileges) and then run another program in the original security context or a different restricted security context then it should be safe.

Forcing programs to be run with ONLY AppArmor and not Bubblewrap restrictions would not be a good thing. A common use of Bubblewrap is for a program to reduce the access of it's child processes which is something it will know about in detail and that AppArmor developers won't necessarily know. Even if AppArmor was configured to restrict child processes (which in many cases could be done) it wouldn't handle the case where an application developer changed their application design and needed matching changes to the restrictions on a child process.

[chris-armstrong]

However looking at the apparmor sources, they seem to have a profile for opam already https://gitlab.com/apparmor/apparmor/-/commit/89a9f7673368e7d19802fd12ec3717a5477200e0 which was shipped in apparmor 4.0.0. Ubuntu 24.04 seems to have apparmor 4.0.1 so in theory it shouldn't be a problem anymore but if it is i'm not sure what was the point of the profile. Does anyone know anything about apparmor and are willing to work with upstream Ubuntu?

Is it possible that this profile only works if opam is installed at /usr/bin/opam (probably the provided system package in Ubuntu) and not if it is installed using the binary distribution?

[WardBrian]

Which is the worse practice here, the above apparmor exception or disabling sandboxing?

[kit-ty-kate]

definitely disabling sandboxing

[gegarcia]

Please don't create an "unconfined" profile for bwrap. This completely bypasses the unprivileged user namespace creation restriction and makes your machine exploitable by attacks that use it.

You should instead create a profile for the application that uses bwrap instead. We have already created one for opam
which is already shipped by the apparmor package.

AppArmor upstream has also created a profile for bwrap that does not make your machine vulnerable. You can find the profile here. It is not enabled by default on Ubuntu, but you can enable it by either copying the file from gitlab, installing it on /etc/apparmor.d/, and load it using sudo apparmor_parser /etc/apparmor.d/bwrap-userns-restrict.

You can also use the version shipped by the apparmor-profile package, and create a symbolic link from the extra-profiles directory to /etc/apparmor.d/
sudo ln -s /usr/share/apparmor/extra-profiles/bwrap-userns-restrict /etc/apparmor.d/
and load it
sudo apparmor_parser /etc/apparmor.d/bwrap-userns-restrict.

[sanette]

Is it possible that this profile only works if opam is installed at /usr/bin/opam (probably the provided system package in Ubuntu) and not if it is installed using the binary distribution?

exactly. I had the same problem after installing opam on /usr/local/bin
but trying again with /usr/bin, then it works! thanks!

[yawaramin]

So...can this issue be actioned in any way by opam maintainers? Or should it be closed?

[kit-ty-kate]

would handling the missing AppArmor profile in the opam install script be enough? This has the advantage of not requiring a fixed version pointing to some documentation to work:

bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/kit-ty-kate/opam/apparmor-install/shell/install.sh)"

I'm not sure what's best to do for people who install opam manually without the script though in the short term.

If that seems reasonable for you all, could you test this script and give me some feedback? I've tested it locally on the Ubuntu 24.04 qemu image and it worked fine. I'll open a PR later in the week if there is no pushbacks