config: Add SECCOMP_FILTER and APPARMOR

[jcberthon]

This change provides updated configuration for bcm2709 (RPi2/3) and bcmrpi (RPi1/Zero) to support user namespaces (which has already been added in rpi-4.6.y+ branches; 24438a3 and d7cbfb8), seccomp filterring (warning, this deactivate CONFIG_OABI_COMPAT, see issue #1605, but I think this is for the better; ad1274c and 1dfa464), AppArmor (341d06b and 9f2b55e).

As added bonus, I have added a few extra changes which offer better control to limit resources of a process or container. These are covered by all other commits of this pull request.

This pull request should address the problems raised in issue #1605 and in issue #1172. They will provide better security for the Raspbian system, and they can be used by container technologies (e.g. Docker but not limited to it) to enhance the containment, resource limitation and overall security. The impact of such change is very limited, there was close to no increase in memory by activating these configs, and the performance were a bit impacted only in worse case scenario with many many system calls. The impact has been documented in issue #1172 and is in my opinion totally acceptable given the advantages :-) .

Note: to apply this pull request to newer branch (i.-e. rpi-4.6.y onward), the commits need to be cherry-pick as the username space commit will conflict with a change already implemented. This is also true for the commits 05fd8f3 and 25cf460 which activate further cgroup resource management configs, but for some they are already present in newer branches. If wished, I can provide different pull request for each branch, just let me know how shall I proceed best.

[pelwell]

Putting aside for a moment the performance, which looks pretty good (perhaps suspiciously so), there is a problem with the SECCOMP patches in that they disable CONFIG_OABI_COMPAT. As discussed in #1605, #652, #766 etc., this is still required for the Raspbian version of gdb, so we are not prepared to remove it just yet.

Debian Stretch is currently set to include gdb 7.11, which contains a patch removing the need for OABI_COMPAT. Stretch won't be ready until early next year, and it will take us some time to base our standard images on it.

Fortunately we have the ability to apply downstream patches to Rapsbian packages before release. @XECDesign already has the patch applied locally, and is prepared to update the published package to include it, at which point we will probably (I'm not the only person to convince) merge these changes and tell people who care to update their gdb.

[jcberthon]

Regarding the performances, my suspicion is that by simply activating the seccomp filtering capabilities that should not impact the performance, except probably if we apply a seccomp filtering profile to a process. But by default seccomp filtering is not used by the system. So for me the little variations between the vanilla and the seccomp kernel are just "noise". What would be interesting is to to a benchmark within Docker when we apply a seccomp profile or when we disable it. But as I mentionned in the issue, the seccomp user space tools are too old in Debian Jessie (although there is a backported version that should work in the Debian Jessie armhf repo), so I cannot use seccomp filtering anyway with Docker.

For AppArmor, this is another story because it is active and running for many processes. And although there are no profile for dd, there is a small performance impact in the worse case scenarios.

As for test3 which looks almost the same across all environments, I suspect we are hitting other performance ceiling, so the kernel changes are not reflected in this test.

What about setting seccomp aside for the time being, but at least merging the other changes?

[pelwell]

The gdb package has now been updated (sudo apt-get update; sudo apt-get install gdb to install - thanks, @XECDesign), so that hurdle has been removed. But since this PR, if merged, will affect all Raspberry Pis, we need some more scrutiny.

The next step might be to merge these commits, or a subset, into the "next" branch, although that may have to wait until the network booting beta has finished with it.

[jcberthon]

That's great news!

All my testing were done on a Raspberry Pi 2 which I use mostly as a low power network server. So it's only one model out of many and for one use case. So it needs indeed further testing on the other platforms and when used in electronic projects (e.g. When using the GPIO I/f) or other use cases.

But I can't help much but continue testing my platform and use case. If you see anything else I could do, let me know.

PS: as a side note, I do not expect much impact as the activated features are not used unless explicitly setup. Even AppArmor is not active if no profile is installed. But of course between what we expect and reality there is often a big difference 😉

[popcornmix]

@jcberthon files in arch/arm/configs should only be created with make savedefconfig (i.e. only include non-default option), never manually edited. (e.g. CONFIG_OABI_COMPAT=n is not a valid syntax, the line should just be removed).

[jcberthon]

Hi @popcornmix

I didn't know, thanks for the info. Do you want me to correct my pull request? Or will you just correct it after merge?

[ghost]

Hi,

I'm not sure this is the correct location to discuss this. Maybe I should open a different issue/etc.

I'm wondering why the need for two completely different files bcmrpi_defconfig and bcm2709_defconfig. Plus, I know this is still in the far future bcmrpi3_defconfig. Especially when I can count on one hand the number of lines that are different.

What I was thinking is why not have a common file with most of the configuration that gets appended with an architecture specific version. Maybe the cat files could then be run through savedefconfig.

Another option maybe to run the standard configuration through a preprocessor first to generate the base configurations.

[djtm]

I can confirm there is no performance hit. I've done some further benchmarking, including a kernel with strong stack protection as well:
http://openbenchmarking.org/result/1611266-SO-APPARMORS15

I even compiled in selinux (though I didn't actively use it, maybe systemd did). The results indicate that apparmor has pretty much no performance impact, strong stack protection has a negible impact (only apache static pages drops). Im my case it's active and running in the background ("Security Performance"). I've used the sources from this repository for all kernels.

A much strong impact comes from heat during the benchmark. The first run is usually the fastest (5 % deviation). I do have a closed case.

I'll next try to compile the software with stack protection as well though that's probably not as much of concern here?

I believe security is a very important issue on these devices. There are many, they are often online 24/7 with several attack surfaces and limited oversight. AppArmor and SELinux are very important tools to shield against attacks. As is stack protection. I believe it should be as easy as possible to users to use them. I would vote for including strong stack protection and maybe even SELinux, e.g. if the kernel is used in Fedora systems.

Compiling your own kernel is not always an option. When I upgraded the git repo with the kernel sources, I had a merge conflict, though I had not changed any source files. That makes upgrading the kernel even slower.

[fpietrosanti]

The GlobaLeaks project would introduce support to run Whistleblowing Platform on Rasberry Pi out of the box if it would only support AppArmor by default. +1

[djtm]

I've been runnig my system for three months with these features enabled (plus strong stack), compiled from source, and I've had no issues (except an unrelated wifi issue recently). Kodi works fine, too.

@jcberthon: If seccomp does not impact performance being disabled, I think there is no issue, since the user can control whether to enable it or not. I'm using the docker arm repo (deb https://apt.dockerproject.org/repo raspbian-jessie main) and I think it's got seccomp and apparmor enabled. Would some further benchmarks help?

[jcberthon]

@djtm I'm also using Docker from the same repo. That particular built of Docker is NOT built with SECCOMP filtering support because it requires the seccomp user space tools to be version 2.2.1 or newer (as I mentioned in this comment #1172 (comment)). However Debian and Raspbian Jessie is using an older version (2.1.1).

Debian has a backported repository in which there is a new version of the seccomp user space tools (backported from testing). However, I have tried to add this repo and install only the libseccomp2 and its dependencies and then recompile Docker to use it, but I can't remember now what was the problem but something did not work, so I reverted the changes.

Just execute docker info and check what Security Options: are reported. If you see seccomp you are all good, if you do not see it, it means it is not available on your platform.

On Raspbian Jessie with my custom Kernel and AppArmor installed:

$ docker info
(...)
Server Version: 1.13.1
Storage Driver: overlay2
(...)
Security Options:
 apparmor
Kernel Version: 4.9.5-v7-lowlat-tick-rtc1307+

[jcberthon]

Note: I've seen that some of the propose changes in my commits (which was forked from the 4.4 branch) are now included in newer branch, so that if you take branch 4.9 there is less changes to be included.

So if you want me to redo the commits and propose a new PR for branch 4.9, just let me know.

[JamesH65]

@jcberthon Please rebase over the latest kernel. @popcornmix @pelwell OK to incorporate this once rebased?

[jcberthon]

Hi @JamesH65

I will try to rebase it during the coming days.

[JamesH65]

Thanks.

[jcberthon]

I wanted to rebase, but that did not work. So I checked out rpi-4.9.y and then cherry picked the commits. Should have the same effect.

I update the pull request, including the title as now in the rpi-4.9.y branch the USER_NS option is already activated.

I'm currently building the kernel and will report if it still works. I do not expect surprises, because I already compile my kernel regularly from the rpi-4.9.y branch with those options plus a few extra ones.

[jcberthon]

Hi @JamesH65

I can confirm that with the above commits I can successfully build the kernel and run it.

LGTM

[JamesH65]

ping @pelwell @popcornmix Seems to me from comments above that we can merge this?

[jcberthon]

Any progress regarding merging?

[pelwell]

I'm guessing you didn't add lsm=apparmor to cmdline.txt.

[Pulsar33]

I'm guessing you didn't add lsm=apparmor to cmdline.txt.

Nice ! Thank you very much.
I confirm it works for me now doing as said above and adding lsm=apparmor in /boot/cmdline.txt

Good job guys !
Best regards
Pulsar33