This would be a patch for snapd. I will look at perhaps doing that but I don’t know how to check which seccomp version is in the kernel. A quick look at /proc and /sys shows nothing appropriate.
It wouldn’t be equivalent to that patch in terms of implementation. snap-confine could detect if seccomp mode 2 is not available and then skip the policy load. Another alternative is to have snapd detect this and if it isn’t available, generate seccomp policy with ‘@unrestricted’ in it (this probably still requires snap-confine changes). The problems with these approaches is that this introduces an attack vector to try to trick the system into disabling the seccomp policy (I had the same reservations for apparmor and from a security perspective prefer compile time options and failing closed, but with the current design, that ship has sailed :).
Ok, well we definitely want to do something that you’re comfortable with security-wise, although we have to disable apparmor and seccomp on our 3.4 kernel for several major reasons.
Ok, so we found a patch set leftover from a proof-of-concept of this product that adds proper seccomp support to the 3.4 kernel from the 3.8 kernel. With these patches applied, snapd/snap-confine are happy enough to successfully run hello-world. Thus we do not need any other changes from @zyga-snapd for this case. Thanks for the discussion everyone!
1 Like
This is great, good luck with the rest!
1 Like
Dear jhodapp,
I’ve have the same issue on a armv7 machine with kernel 3.4.90, snapd 2.26.1.
When I run hello I get:
cannot open mount namespace of the init process (O_PATH): No such file or directory
I’m kind of newbie with snap, kernel and apparmor.
Could you kindly explain a little bit more your solution? Which patch did you used?
Kind regards,
Patrick
A 3.4 kernel should be sufficient but you may be missing a kernel patch for a bugfix or two. Can you please ensure that your kernel configuration has namespaces enabled?
Hi Zyga,
thank you for the quick answer.
I just checked kernel configuration. Namespaces are enabled.
Interesting, do you see any aparmor denials (dmesg | grep DENIED) and is /proc/1/ns/mnt a file?
No apparmor denial and /proc/1/ns/mnt doesn’t exist.
In the meantime something changed. I went back to the previous version 2.24 (from the official Debian repository - before I used 2.26.1 by “stealing” from ubuntu repo but I thought that this would cause some problems). Now with the “official” 2.24 I have the following error:
/snap/bin/hello-world
cannot bind-mount the mount namespace file /proc/5344/ns/mnt -> hello-world.mnt: No such file or directory
support process for mount namespace capture exited abnormally
No messages in dmesg, but I have this in syslog:
May 25 15:02:36 /snap/bin/hello-world[5387]: cmd.go:105: DEBUG: restarting into “/snap/core/current/usr/bin/snap”
May 25 15:02:36 rsyslogd-2007: action ‘action 17’ suspended, next retry is Thu May 25 15:04:06 2017 [try http://www.rsyslog.com/e/2007 ]
May 25 15:02:36 /snap/bin/hello-world[5387]: cmd.go:59: DEBUG: re-exec disabled by user
Any clue? I’m totally lost
If you don’t have /ns/mnt then your kernel is too old or has some other patches missing. You absolutely want the patches that enable setns to work.
Also make sure that your kernel has this patch in it, this should help with what you’re seeing: https://lists.linuxfoundation.org/pipermail/containers/2012-November/031023.html