AppArmor blocks TUN device creation, breaking tools like opencode

[tito]

Description

When running greywall -- opencode, the sandbox blocks TUN device creation and RTNETLINK operations, preventing opencode from setting up its networking:

RTNETLINK answers: Operation not permitted
ioctl(TUNSETIFF): Operation not permitted
Cannot find device "tun0"
Cannot find device "tun0"
Cannot find device "tun0"
ERROR 2026-03-24T22:01:37 +62ms service=models.dev error=Unable to connect. Is the computer able to access the url? Failed to fetch models.dev

Root cause

This appears to be caused by AppArmor restricting the ioctl(TUNSETIFF) and RTNETLINK operations inside the bubblewrap sandbox. The tool tries to create a TUN device for its own networking, which AppArmor denies.

Reference: https://docs.monadical.com/j0hgdOyRQea_f8SWIYJwPw#

Environment

• greywall v0.2.8
• greyproxy v0.3.2
• Linux kernel 6.17
• Platform: linux

Steps to reproduce

1. greywall check (all checks pass)
2. greywall -- opencode
3. Observe TUN/RTNETLINK errors and network failure

Expected behavior

opencode should be able to reach the network through greyproxy's SOCKS5 proxy without needing to create a TUN device, or AppArmor should allow the necessary operations for tools that require TUN devices.

[rsyring]

For the record, it's not just opencode, it also breaks on something simpler like the getting started example:

 ❯ greywall curl https://example.com
RTNETLINK answers: Operation not permitted
ioctl(TUNSETIFF): Operation not permitted
Cannot find device "tun0"
Cannot find device "tun0"
Cannot find device "tun0"
curl: (6) Could not resolve host: example.com

[cowpig]

@rsyring my workaround for this today was to run

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

[rsyring]

@cowpig thank you but that disables an OS level security restriction, which I'd prefer to leave in place. See #57 for more information.

Although, that recommendation gives me an idea. If this is an app armor caused restriction, maybe it can be solved through an app armor profile adjustment.

[tito]

@cowpig it was this plus the 2 apparmor profiles we created for greywall and wrap.

We have to properly make them available during installation, but might need expert to validate them first.

[rsyring]

@tito: do you have an example of the apparmor profiles that I could review? That would fix this TUN issue?

[tito]

@rsyring Yes here they are, they are basically quite open as a fast patch to make it work. If you have any advise or know how to constrain them to just having the issue resolve, that would be excellent:

GREYWALL_PATH=$(which greywall)

# greywall profile
echo "abi <abi/4.0>,
${GREYWALL_PATH} (unconfined) {
userns,
}" | sudo tee /etc/apparmor.d/greywall

sudo apparmor_parser -r /etc/apparmor.d/greywall

# brwap profile
echo "abi <abi/4.0>,
/usr/bin/bwrap (unconfined) {
userns,
}" | sudo tee /etc/apparmor.d/bwrap

sudo apparmor_parser -r /etc/apparmor.d/bwrap

[rsyring]

So, I was able to copy bwrap-userns-restrict policy which ships on Ubuntu 24.04 and:

# remove in the second block
audit deny capability,

# add in it's place
capability net_admin,
capability net_bind_service,

The full file is: cat /etc/apparmor.d/bwrap-greywall

# This profile allows almost everything and only exists to allow
# bwrap to work on a system with user namespace restrictions
# being enforced.
# bwrap is allowed access to user namespaces and capabilities
# within the user namespace, but its children do not have
# capabilities, blocking bwrap from being able to be used to
# arbitrarily by-pass the user namespace restrictions.
#
# Note: the bwrap child is stacked against the bwrap profile due to
# bwraps use of no-new-privs

# disabled by default as it can break some use cases on a system that
# doesn't have or has disable user namespace restrictions for unconfined
# use aa-enforce to enable it

abi <abi/4.0>,

include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(attach_disconnected) {
  allow capability,
  # not allow all, to allow for pix stack
  # sadly we have to allow  m every where to allow children to work under
  # stacking.
  allow file rwlkm /{**,},
  allow network,
  allow unix,
  allow ptrace,
  allow signal,
  allow mqueue,
  allow io_uring,
  allow userns,
  allow mount,
  allow umount,
  allow pivot_root,
  allow dbus,
  allow px /** -> bwrap//&unpriv_bwrap,

  # the local include should not be used without understanding the userns
  # restriction.
  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/bwrap-userns-restrict>
}

profile unpriv_bwrap flags=(attach_disconnected) {
  # not allow all, to allow for pix stack
  allow file rwlkm /{**,},
  allow network,
  allow unix,
  allow ptrace,
  allow signal,
  allow mqueue,
  allow io_uring,
  allow userns,
  allow mount,
  allow umount,
  allow pivot_root,
  allow dbus,

  allow pix /** -> &unpriv_bwrap,

  # WARNING: unsure of the security implications of these next three lines
  # audit deny capability, (commented out line which was originally present)
  capability net_admin,
  capability net_bind_service,
  
  # the local include should not be used without understanding the userns
  # restriction.
  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/unpriv_bwrap>
}

I worked with ChatGPT to get to this point and asked it if this was the best we could do in terms of locking things down. It said:

Yes, but mostly by changing behavior, not by somehow keeping the same full-capture model without the needed capabilities.

Greywall’s own docs say two things that matter here:

First, on Linux its full traffic capture design is specifically unshare-net + tun2socks + a DNS bridge. In other words, the current “capture everything” path is built around a TUN device and a private network namespace. ([docs.greywall.io]1)

Second, Greywall’s troubleshooting page says that when CAP_NET_ADMIN is unavailable, it should fall back to no network namespace isolation and keep using proxy env vars like HTTP_PROXY / HTTPS_PROXY. It also says that in fallback mode, apps that do not honor proxy env vars will not be isolated, and Node’s built-in http/https modules are a concrete example. ([docs.greywall.io]2)

So the clearest thing Greywall could do is:

1. Actually make the documented fallback work reliably on Ubuntu 24.04.
That is the big one. In your case, Greywall kept trying the TUN path instead of cleanly degrading to env-proxy mode. Based on its docs, that looks like a bug or incomplete fallback behavior. ([docs.greywall.io]2)

2. Add an explicit “force fallback / env-proxy-only” mode.
That would let a user say, “do not try TUN, do not try the DNS bridge, just run with ALL_PROXY / HTTP_PROXY / HTTPS_PROXY.” Greywall already uses exactly that model on macOS, where it documents that there is no full traffic capture and only apps that honor proxy env vars are redirected. ([docs.greywall.io]1)

3. In fallback mode, avoid binding privileged DNS entirely.
Your testing showed that net_bind_service was needed because Greywall’s current DNS relay binds UDP 53 inside the sandbox. If Greywall is already in reduced mode, it could choose not to run that DNS relay at all and instead rely on app-level proxy behavior, especially SOCKS/HTTP proxy modes where the proxy can do remote DNS resolution for cooperating clients. That would reduce the required capabilities, but it would also reduce coverage. This last point is an inference from the architecture and your test result. ([docs.greywall.io]1)

What Greywall probably cannot do, at least not with its current Linux architecture, is provide the same transparent, app-agnostic, full-capture behavior with no extra capability at all. Their own platform docs tie Linux full capture to TUN and network namespaces, and their troubleshooting docs describe the non-capability case as a reduced fallback mode, not an equivalent replacement. ([docs.greywall.io]1)

So my read is:

• Yes, Greywall could work without those extra capabilities by improving and exposing its fallback path.
• No, Greywall likely cannot offer the same “capture all outbound traffic transparently” guarantees without them, unless it adopts a substantially different architecture.

The most practical product change would be a user-selectable mode like:

• full = current TUN/DNS-bridge model
• auto = try full, then clean fallback
• proxy-only = never attempt TUN or privileged DNS

That would fit both its Linux and macOS models as documented.

I wouldn't normally copy & paste LLM output but I thought the suggestions seemed reasonable.

HTH.