Some specific sysctls are already tied to other namespaces, e.g. ip_unprivileged_port_start is per network namespace[0]. There also are a few per userns sysctls for resource limits.
> What other kinds of namespaces are people thinking about?
I would really love to have something like a device namespace, i.e. being able to split up exclusive device ownership to different namespaces similar to network namespaces.
It would allow a container to see a subset of devices and the root of the containers user namespace would actually be allowed to operate on them while other device namespaces no longer see those devices.
This would also allow containers to create their own loop back devices and loop mount things (as root user of that user namespace that is mapped to a non-root user in the parent).
Time namespaces that allow you to change the real time duration of a system time second, or to outsource the clock, for testing and debugging purposes among others.
I'd heard that there were some.. risk of increased attack surface, lets say, by allowing userland access to namespaces for devices/mount points, but I'm not familiar with what this would really look like. What could be done to mitigate these security concerns so that everyone is comfortable enabling it?
"increased attack surface ... but I'm not familiar with what this would really look like"
There's a related LWN article on this called "Anatomy of a user namespaces vulnerability" [0].
Basically, the kernel has a bunch of places where it checks for various capabilities. Unprivileged usernamespaces let you gain various capabilities in a limited fashion, but those limitations are based on the kernel itself recognizing that you only have those capabilities in said limited fashion.
For an easy example, a root user in a usernamespace (aka an unprivileged user on the host) is allowed to mount a new tmpfs in their namespace, or mount proc... But it's still not allowed to mount /dev/sdx since that device belongs to the real root user.
Necessarily, that means there are different ways to check if someone has permission than the simple "is the caller uid 0"; there has to be for tmpfs "are they CAP_SYS_ADMIN in their current namespace", while for /dev/sdx it has to be "CAP_SYS_ADMIN in the root namespace".
It simply amounts to there being more total codepaths that an unprivileged user can reach because, for example, they can now pass the tmpfs mount check (intentionally), and perhaps there's a mount option that wasn't fully thought through.
"What could be done to mitigate these security concerns"
Docker's seccomp filters would have actually stopped quite a few exploits here by totally gimping user namespaces to be useless. So yeah. maybe that's not the answer.
There's really not an answer though. You can't prove something is secure and bug-free. It has been a while since a really meaningful userns exploit and there are a lot of people that believe it to be a useful thing to have.. a bunch of distros have enabled it. People are still wary because of its history. I think at this point all that's left to mitigate these concerns is time. The implementation isn't likely to change drastically any time soon.
Looking more closely at it, this only seems to implement clock offsets rather than changing the length of a second. Changing the actual rate of system time progress would be helpful for a number of things including finding time-based synchronization errors.
Live migration of virtual machines is kernel independent. The guest VM can be running a unikernel, BSD, Windows, etc. The interface the guest uses to sync or retrieve time depends on whether the guest reads the virtualized hardware clock (goes by many names) or a paravirtualized API is used (such as kvm-clock).
What other kinds of namespaces are people thinking about?
[1]: http://man7.org/linux/man-pages/man7/namespaces.7.html