Disabling seccomp sandbox where a buggy golang-seccomp is used

snapd
1

I discovered that https://bugs.launchpad.net/snapd/+bug/1825052 is a serious bug in our seccomp sandbox for any snapd distro packaging that uses a golang-seccomp without https://github.com/seccomp/libseccomp-golang/commit/06e7a29f36a34b8cf419aeb87b979ee508e58f9e since without the patch, golang-seccomp (and therefore snap-seccomp) will generate invalid and lenient bpf for seccomp filters with rules where 2+ arguments are being filtered. This affects the following seccomp policy:

  • setpriority in the default template
  • chown family of rules in the default template
  • socket rules in various interfaces
  • the upcoming daemon user PR

snapd’s own vendored golang-seccomp includes this patch and is not affected, so any distro packaging uses snapd’s vendored golang-seccomp is not affected. The latest upstream release of golang-seccomp is 0.9.0 and it is affected. Distros known to not use our vendored golang-seccomp and therefore affected are Debian (before it refreshes core and reexecs) and Fedora.

@pedronis, @mvo, @zyga-snapd - I consider this serious enough that as an immediate first step we should disable seccomp on the distros that choose not to use the vendored golang-seccomp. Beyond that, there are other options such as compile time checks to verify the pfc, a spread test that will fail for systems with seccomp enabled but arg filtering not working correctly, additions to system-key, runtime checks for forced devmode based on system-key, etc.

Note: while this is a serious bug I do not consider it a security bug (though it was very nearly so). I say ‘very nearly’ because this bug does not affect systems using snapd’s vendored and unaffected golang-seccomp (eg, Ubuntu, Ubuntu Core, any Ubuntu derivatives, etc) or any system configured with reexec since an unaffected snap-seccomp is used. In practice this means that only systems with partial confinement are affected. Because the seccomp sandbox alone does not offer meaningful protection without AppArmor, there are many more escapes from the ‘sandbox’ (again, partial confinement is not considered a true sandbox) than the list I gave above.

1 Like
2

I meant to mention, another possibility is to unconditionally use snap-seccomp from the core/snapd snap, regardless of reexec. It only processes what is on disk and doesn’t reach out to snapd and is statically linked. An interesting side-effect of this is we can make the whole thing more robust since there is only one version of golang-seccomp (the vendored one, or anything we choose to update to) and a version of libseccomp that comes from the Ubuntu archive or an upstream git tag (so we can roll out 2.4.1 more easily).

3

Fedora recently updated to libseccomp-golang 0.9.0 release. I’ve double checked that the package does not have the patch and filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1702169 (cc @Conan_Kudo)

Edit: updated package has already been submitted to testing repo. I’ve verified that the test case described in bug report behaves correctly when snapd package is rebuilt.

1 Like
4

I created a debian PR on https://salsa.debian.org/go-team/packages/golang-github-seccomp-libseccomp-golang/merge_requests/1 with the cherry-picked fix.

1 Like
5

@jdstrand I find it a bit odd that upstream has not released on updated golang-libseccomp yet. This seems to be a CVE in that lib - anything that uses golang-libseccomp to generate fitlers for multiple arguments will be broken. Granted we may be the only one doing this but who knows? If you agree I will contact upstream and urge for a new upstream release.

6

Maybe filing a CVE out of it will speed-up the process? :wink:

7

FYI, I requested a CVE and contacted upstream: https://github.com/seccomp/libseccomp-golang/issues/22#issuecomment-486322303

3 Likes