Programming language can know more about the program's (intended) state at any given time. The OS can/should frequently be involved, but even then you're frequently doing something like pledge() from the program to let the OS know when/how to restrict you. Doing it totally externally, like SELinux does, is valuable but coarser-grained.
Pledge and SELinux are the same level of graininess but pledge’s sauce is that the app has a channel to ask the OS for process restrictions where SELinux has to be applied in advance.
I think it's reasonable to describe one as more coarse gained when it simply doesn't have enough information to be as precise as the other method. Yes, they work at the same layer and can do vaguely the same things, but s targeting makes a huge difference.
Yes, and you can even have a single process with threads in multiple namespaces. But it still doesn’t solve the problem unless you magik passing all log messages to a dedicated pool of threads just for logging.
The process is simply the wrong layer for this boundary, it’s too coarse and trying to hack your way into telling the OS about the parts of your program. OS security treats processes are black boxes, just like hypervisor security treats vms like black boxes. Trying to force it will be extremely clunky.
The Linux kernel developers don't recommend using namespaces for security, but only for access control (the two are not the same!) because it's a relatively recent concept and the syscall interfaces and semantics are huge and subtle. Dedicated user accounts together with firewall rules are a better idea IMHO.
