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

Question

Many administrators turn off seccomp on their containerization platform in a trade-off with ease of use/application.

However turning off such a basic security setting that is so heavily tied to sandboxing is, to some extend, defeating the purpose of containerization. From a security/stability point of view I would think it to be wise to keep blacklisting most of the system calls when running the LXC/Docker containers on servers (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?

*Bonus question: What would be the risks when assuming one is the only one using the "mother" system and its LXC containers (e.g. in an experimental test laboratory, where it may be less evident to have multiple users, but containerization still offers many benefits such as easy snapshoting / cloning of experimental environments)?

Answer 1

Security is not a absolute thing as you seem to assume: no thing is dangerous by itself, things are only dangerous when considering a specific threat.

Security can only be defined against a set of precised and factual threats which may affect your platform intended use.

What you say in your question, as per my understanding, is that you do not plan to use LXC for security purpose (ie. you do not rely on LXC to isolate a compromised application for instance), instead you rely on LXC solely for make cloning and snapshoting local personal experimental environments easier.

From that, the only thing that would matter is may the use of LXC decrease the security of the underlying system in any way: the answer is no, at worse LXC will provide no security benefits but it will not decrease the security of the underlying system (it will have merely the same effect as a chroot). Running an application on an LXC enabled machine will not be less secure that running the same application on the same system with no LXC.

Do not forget though that, if you use LXC to store complete Linux systems (which I think is the most common case), the same security hygiene rules applies both to the host and guests systems:

• Do not use weak passwords,
• Apply security updates,
• Etc.

For a development machine, depending on your actual needs, the attack surface can be greatly reduced by preventing LXC hosted services from be reachable over the network. By keeping such application to listen only on local interfaces, you keep the ability to develop what you want while still ensuring that a remote attacker will not be able to leverage some flaw in your work or the underlying guest to access your system.

As per technical application / stability issues, I am not aware of anything particular. If you encounter any such issues, it should be dealt with individually either on Unix.SE or LXC mailing list for instance.