How dangerous is it not to load `seccomp` rules for LXC containers?

Question

Context

In my "quest" to get LXC to run on Raspbian I may be forced to disable loading the seccomp configuration at container startup, by commenting it out in /usr/share/lxc/config/debian.common.conf:

# Blacklist some syscalls which are not safe in privileged
# containers
#  lxc.seccomp = /usr/share/lxc/config/common.seccomp

As (a.t.m.) only than the container starts (otherwise an error is raised)..

Turning off such a basic security setting that is so heavily tied to containerization/sandboxing is, to some extend, defeating the purpose of LXC. From a security/stability point of view I would very much like to keep blacklisting most of the system calls when running the LXC containers (as configured by LXC defaults in /usr/share/lxc/config/common.seccomp):

2
blacklist
[all]
kexec_load errno 1
open_by_handle_at errno 1
init_module errno 1
finit_module errno 1
delete_module errno 1

Questions

Does not 'loading seccomp rules for LXC containers' yield:

1. significant * security issues?
2. any other technical (application or stability) issues?

*Assuming I am the only one using the "mother" system and its LXC containers (otherwise it would be evident..)

Answer 1

Well, the seccomp rules prevent a container from modifying the host kernel. Without them, UID 0 in a container can use kexec(if that even works on Raspbian, I'm not sure) to load a new kernel(apparently not to start it) and insmod/rmmod to load/unload modules among other things as these syscalls don't take user namespaces into account correctly.

Whether this is a significant security issue is up to you - you just need to keep in mind that now UID 0 in the container can effectively become UID 0 outside of the container, i.e. it's possible for root to escape the container by loading a crafted module for example.