“what most are using today which is namespaces?”
Who is this “most” you speak of? I was unable to find anyone doing jail type configurations for shared hosting with namespaces/cgroups, and believe me I searched!
I’ve been working on namespaces/cgroups stuff for a while now, as well. But, as far as I can tell it’s not quite ready for use as a user isolation tool (it’s getting very close, though, but it’ll be maybe years before stock kernels in our most popular distros have the necessary bits). There’s process isolation, network isolation, etc. but no user isolation in older kernels (and we have to support older kernels). I did a bunch of experiments before settling on Jailkit as our near-term way forward on this feature, but couldn’t figure out how to make it work with namespaces and cgroups.
The issues with chroot jails have mostly been resolved. Our jailkit build uses kernel capabilities (rather than suid 0), the Jailkit commands protect users against the most common mistakes people make when building jails, and we’ll be bind mounting homes so that the various other parts of the system don’t need to change or have additional privileges. And chroot no longer breaks privilege separation in openssh, which was a major factor in my always saying no in the past to chroot jails. Historically, the risk with jails was not just that someone might break out of the jail, but that breaking the jail potentially meant escalating to root. I was never comfortable with that state of affairs, but those issues have been resolved for a couple of years now (long enough for all of the bits to make it into all of the operating systems we support).
But, I should be clear that I have never once recommended a chroot jail as a security feature (you’ll find me ranting about it all over these forums), but there are tons of users who want it. It’s not hard to implement, so we’re adding it. I will still never claim that a chroot jail is more secure. But, many users want that belief of isolation among their users.
The reasons we aren’t using namespaces (yet):
The tools available for managing them are in their infancy, and none (that I’ve found) are focused on isolating human users. They are mostly targeted toward service-based architectures (which is another useful area of development for Virtualmin, but it’ll come late). Containers do not yet contain, very well, is what I’m trying to say, especially in older kernels.
So, the reasons for Jailkit support are:
- Users have been asking for it for years. The primary reasons I always said “no” have been resolved.
- Namespaces/cgroups do not have tooling for isolating users; there is nothing comparable to Jailkit for namespaces (Docker is close, but having a user login shell inside a docker is almost antithetical to their intended model, so it doesn’t get a lot of attention).
- Namespaces/cgroups support in the kernels for the older operating systems we support lacks a number of the features needed to actually be safe for users to have access to. Again, we’re back to the “breaking the jail might allow more damage than just escaping the jail” problem that chroot jails had for many years. I think the current kernel has fixed all that, but it’ll be a while before we can rely on it being available on our supported distros. Probably need to wait until CentOS 6 and Debian 7 and Ubuntu 14.04 are EOL.
All that said, if you’re enthusiastic about namespaces/cgroups for user isolation, and you want to help accelerate that development, I’d be happy to have someone else involved. We can make it happen during the Virtualmin 6 cycle, as a beta plugin, if the kernel support is there on CentOS 7 and Ubuntu 16.04 (I’m not sure it is, but we could sort it out).
I don’t like chroot jails. Never have. They’re mostly snake oil security. But, many people really want them and think Virtualmin is insecure because of its lack of them (I’ve seen the “Virtualmin is insecure because users can see outside of their home” argument way too many times now by folks who have no idea how chroot works or its history of exploit risk). So, we will support them in a way that doesn’t alter the experience for users who don’t turn them on, and only moderately effects users who do turn them on. We’ll work on namespaces/cgroups for the future.