syscall: TestAmbientCapsUserns fails on Ubuntu 24.04/Linux 6.8.0

[ulikunitz]

Go version

go version go1.22.2 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/kunitz/.cache/go-build'
GOENV='/home/kunitz/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/kunitz/work/pkg/mod'
GONOPROXY='github.com/ulikunitz,doppelwuerfel.de/home/kunitz/git'
GONOSUMDB='github.com/ulikunitz,doppelwuerfel.de/home/kunitz/git'
GOOS='linux'
GOPATH='/home/kunitz/work'
GOPRIVATE='github.com/ulikunitz,doppelwuerfel.de/home/kunitz/git'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/kunitz/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/kunitz/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.2'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/kunitz/go/src/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2527480546=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I installed Ubuntu 24.04 and compiled go 1.22.2 using go 1.20.14 for bootstrapping. all.bash ran into two errors. Investigating the second I changed into go/src/syscall and executed go test and run into the failure again.

Interestingly TestAmbientCaps is skipped because the exec returns operation not permitted.

What did you see happen?

~/go/src/syscall$ go test
CAP_SYS_TIME unexpectedly not in the effective capability mask
--- FAIL: TestAmbientCapsUserns (0.01s)
    exec_linux_test.go:752: exit status 2
FAIL
exit status 1
FAIL	syscall	0.565s

Info about environment:

##### Test execution environment.
# GOARCH: amd64
# CPU: AMD Ryzen 7 3700X 8-Core Processor             
# GOOS: linux
# OS Version: Linux 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64

What did you expect to see?

No error executing go test in go/src/syscall.

[ianlancetaylor]

CC @stapelberg

[thediveo]

AppArmor?

[ulikunitz]

I put AppArmor in complain mode and the test is now successful. Note that I did the default install and didn't change anything on the apparmor configuration. It appears that profile unprivileged_userns is causing the issue.

I find the following in syslog in complain mode:

2024-04-28T22:15:25.972777+02:00 dragon kernel: audit: type=1400 audit(1714335325.971:157): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=4779 comm="syscall.test" requested="userns_create" target="unprivileged_userns"
2024-04-28T22:15:25.972779+02:00 dragon kernel: audit: type=1400 audit(1714335325.972:158): apparmor="ALLOWED" operation="capable" class="cap" profile="unprivileged_userns" pid=4786 comm="syscall.test" capability=6  capname="setgid"
2024-04-28T22:15:25.972785+02:00 dragon kernel: audit: type=1400 audit(1714335325.972:159): apparmor="ALLOWED" operation="capable" class="cap" profile="unprivileged_userns" pid=4786 comm="syscall.test" capability=7  capname="setuid"

With app_armor in enforce mode in I find the following:

syslog.1:2024-04-27T22:26:48.453999+02:00 dragon kernel: audit: type=1400 audit(1714249608.452:5838): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=821266 comm="syscall.test" capability=6  capname="setgid"
syslog.1:2024-04-27T22:26:48.454001+02:00 dragon kernel: audit: type=1400 audit(1714249608.452:5839): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=821266 comm="syscall.test" capability=7  capname="setuid"
syslog.1:2024-04-27T22:26:48.889023+02:00 dragon kernel: audit: type=1400 audit(1714249608.887:5842): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=821534 comm="syscall.test" capability=21  capname="sys_admin"

[ulikunitz]

I can confirm

$ sudo aa-disable unprivileged_userns

prevents TestAmbientCapsUserns from failing in a persistent manner.

[ulikunitz]

I have been made aware that there is a section in the Ubuntu release notes that describes the issue.

[stapelberg]

To me, it sounds like Ubuntu comes with too-locked-down defaults for development of sandboxing features, but as per the release notes you link, that seems intentional and users are expected to follow one of the possibilities mentioned in the release notes.

Other environments (e.g. corporate laptops) also come with similar restrictions (malware scanners that use an allowlist to control which software runs) that need to be turned off for development.

So is there anything left to be done on the Go side here?

Should we maybe skip the test when we detect apparmor being active? Or adjust the error message to point to the Ubuntu release notes?

[thediveo]

what about an upstream issue so that Ubuntu fixes this? they broke it, they own it.

[ianlancetaylor]

Is there any way that the test can detect the problem and simply skip the test in that case?

Our goal here should be for the test to pass or be skipped on all systems. We shouldn't change the behavior of the non-test code, though we may want to document the problem. But the test should not fail.

[ulikunitz]

The test could be skipped if /proc/sys/kernel/apparmor_restrict_unprivileged_userns exists and is set to 1.

Unfortunately the flags that control how apparmor will behave (apparmor_restrict_unprivileged_userns_complain and apparmor_restrict_unprivileged_userns_force) are not readable by an unprivileged user, so the test will be skipped even in cases when it may be successful because the apparmor profile is deactivated.

[stapelberg]

After reading https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction#checking-the-current-state-of-restricted-unprivileged-user-namespaces and the following sections, I think we should:

• check if /proc/sys/kernel/apparmor_restrict_unprivileged_userns is 1 and skip the test
• document this restriction

The _complain and _force modes seem like rare enough (for machines where you want to develop Go, not for servers on which you would run production programs) that they don’t warrant special handling.

I can send a CL for these updates tomorrow.

[gopherbot]

Change https://go.dev/cl/585059 mentions this issue: syscall: skip TestAmbientCapsUserns when restricted, document