Mount namespaces and user namespaces have been a ripe area for Linux exploits. Many of the local privilege escalation exploits published since the shift to containers involved this code--either bugs in the code or because of unexpected, unintended consequences.

The reason why only root can call chroot is because the ability to change the namespace can cause havoc with other privileged code not expecting the namespace to be mutable in certain critical respects. chroot originally didn't require root permissions, but then people figured out all the security problems it caused in the Unix privilege model. And because it was so difficult to fix comprehensively given that model, the solution adopted was to limit it to root.

That difficulty is why more sophisticated and malleable namespace solutions were avoided for so long. And the recent history of exploits in Linux has only proven the original wisdom of that. Adding more complexity and degrees of freedom to namespaces (the ability to create isolated namespaces) only exacerbates those problems. And it's triply stupid to allow non-root users to manipulate namespaces like that, which is what Linus finally allowed and which some Linux distributions began allowing by default before more exploits were published. It's an approach that makes sense in many other contexts, but not in the context of the Unix process and privilege model. It works very well in Plan 9, but Plan 9 was carefully designed to avoid the same design decisions in Unix that make mutable namespaces so problematic.

seccomp doesn't save containers. It has zero to do with containers. It's a simple mechanism to limit syscalls by syscall number. In an abstract sense that's a namespace related issue (syscalls are in a shared namespace, and syscall numbers are paths into that namespace), but it's a real stretch to see that as a facet of containerization.

Containers can help people develop security solutions. I won't dispute that. They're a tool, just not one that is usefully scene as a principally security tool.

Regarding PID namespacing and signaling, that's just FUD about chroot jails. The PID namespace is indeed unaffected by chroot, but in a chroot jail you setuid to an unprivileged user. That's part of the protocol of a chroot _jail_. An unprivileged user cannot directly send signals to other processes without the same UID. On systems like OpenBSD every service is assigned a unique UID. On Linux the nobody user is too often abused, but major services like databases are still usually assigned a unique UID and so cannot be signaled by a chroot-jailed, unprivileged process. It's even possible to assign random UIDs to processes (e.g. among slave processes), as the kernel doesn't care what the integer value is as long it fits within some predefined range.

The chroot jail protocol is hackish, but I can't recall a bug in Linux or any other Unix that permitted an unprivileged user process to directly signal processes of a different user. Nor can I recall a bug in kernel chroot implementations that violated the defined semantics, at least not where Linux's new namespacing features weren't involved.

Given the reality of security issues on modern systems--that kernels are so complex that there's an endless bounty of exploits at the user-kernel interface, the chroot jail is a singularly simple and effective solution that addresses that problem, at least before pledge, seccomp, and capsicum came onto the scene.