Kernel Options for systemd 231

[crazy4chrissi]

I compiled a kernel as described here:
https://www.raspberrypi.org/documentation/linux/kernel/building.md
This kernel would not boot properly on Arch Linux with systemd 231. The problem and its solution is described here:
https://www.danand.de/index.php/2016-08/solution-to-systemd-231-seccomp-error-on-allwinner-soc/
With these kernel options, systemd 231 worked well for me:
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECCOMP=y
CONFIG_OABI_COMPAT=n

[popcornmix]

Arch produce their own kernel. Our default settings are chosen for raspbian.
If there are no downsides we would consider options that are useful for Arch, but CONFIG_OABI_COMPAT was required for #766

[crazy4chrissi]

Okay, then probably let's postpone this until Raspbian embraces systemd 231, which might take a couple of years... ;-) currently, systemd 231 is in Debian sid only https://packages.debian.org/sid/systemd

[sandersr]

Same problem on Fedora 25 and official RPI kernel. Any reason why are these settings disabled:
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECCOMP=y
?

[pelwell]

CONFIG_SECCOMP=y and CONFIG_OABI_COMPAT=y are both in the standard configurations, but not CONFIG_HAVE_ARCH_SECCOMP_FILTER=y or CONFIG_SECCOMP_FILTER=y.

As I said in issue 1172:

With all kernel options that aren't simply loadable modules we are concerned about increased kernel size and reduced performance. If you were to present "before and after" comparisons of free memory and performance (using some standard benchmarks) it may strengthen your case.

[Ferroin]

The issue with CONFIG_SECCOMP_FILTER is actually that we have CONFIG_OABI_COMPAT=y, which is itself needed by the old version of GDB in Raspbian. There was talk that it might get patched locally so it doesn't need that, but I don't think that actually happened.

[clivem]

There was talk that it might get patched locally so it doesn't need that, but I don't think that actually happened.

Didn't @popcornmix already get a patch into Raspbian, so that CONFIG_OABI_COMPAT isn't required for gdb to be vaguely useful.

This is turning into deja-vu and these reports are going to keep coming, time and time again, with the newer distributions using the later systemd version which is requiring FILTER if CONFIG_SECCOMP=y.
Either CONFIG_OABI_COMPAT=n && enable SECCOMP_FILTER option, or disable SECCOMP entirely, if you still need CONFIG_OABI_COMPAT, sorts the problem, when I looked at it a couple of weeks ago.

[jcberthon]

And now that the officlal Raspberry Pi blog announced Docker running on it, there will be more and more people like me who wants to run unprivilege and really contained containers, and not simply a slightly better chroot. ;-)

So indeed I want SECCOMP (and its filters based on bpf) and user namespace to be compiled in. :-)

[JamesH65]

@popcornmix The referenced issue has some performance figures.

[JamesH65]

AFAICT, all the required SECCOMP settings are present in the latest kernel, so please test and close as necessary.

In the meantime, this issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

[JamesH65]

Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.

[jcberthon]

Hi @JamesH65

First sorry for my low responsiveness. I'm currently taking a bit more care of my family and therefore I have less time for open source projects, or let's say it's less regular now.

Anyway, yes the SECCOMP configuration is now mainlined and I can see it also that now Docker supports seccomp on Raspbian Stretch out-of-the box! Thank you!

However, AppArmor is still not mainlined although my PR #1698 was containing also changes related to AppArmor. Perhaps if AppArmor or SELinux are not considered for default, they could be compiled as modules and thus people interested in activating them would not have to resort in compiling their own kernel. What do you think?

Now for the Kernel MAC (aka AppArmor, SELinux et al), shall we reopen this issue (and perhaps change the title) or shall I create a new issue?

Here is the output of the Kernel config from a vanilla installation of Raspbian Stretch with the latest stable Kernel (showing only the relevant part):

$ uname -r
4.14.62-v7+
$ zegrep "APPARMOR|SECURITY|SECCOMP" /proc/config.gz
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECCOMP=y
[...]
# CONFIG_SECURITY is not set
[...]

One can see that SECCOMP is activated 👍

And one can see that none of the Kernel MAC are configured, not even as module.