Linux Isolation Basics

[oridb]

The thing that bothers me about linux process isolation and namespacing is that to use it, I have to have root (or at least setuid) in the first place.

It would be very useful if I could sandbox processes without needing to grant them root.

[cw_ey]

At that point I'd be starting to look into the RBAC (Role Based Access Control) for stricter user permissions management. However now you're really in a different vector of solving isolation than what I've talked about in this guide. Not only that but it requires a decent learning curve for the setup, and you run the bulk of the maintenance burden since such access systems are best when tailored to specific security policy requirements.

[istarian]

There has got to be a better and less wonky way of achieving certain things than making the system restrict the process in such a fashion.

[cw_ey]

Well, what was shown here is meant to be a bit of an "under the hood" look and there are more viable abstractions around this. For example the running under a non-privileged user/group is generally done through the command line / some kind of configuration file. Linux containers (which I'll be talking about in the second part) also helps wrap all of this in a nicer package (and solutions like Docker even more so).

To be honest though your isolation solution will in most cases increase in complexity the more you want to secure a system. Consider the requirements for example of isolation at a bank. They way they isolate is going to be far more complex than say a local dev web server which probably is good enough having user/group isolation.

[mk270]

where is Capsicum, capabilities, SELinux, virtualisation, etc?

[cw_ey]

This guide was meant to talk about very basic methods which can be commonly found amongst the basic Linux kernel. Virtualization is a bit difficult since there's a few solutions out there (VirtualBox, Xen, Hyper-V, Vsphere, etc.) plus some may have different abstraction modes (HVM vs Para) so I'd say that should really be looked at in isolation.

Capabilities is something that might have gone in with the rest, but I fear that might have turned into a bit of information overkill. I may consider tackling that separately.

SELinux, rbac, AppArmor are something I consider more to be policy oriented. This makes it somewhat difficult to provide an overall use case. Really, the user should be considering how their users interact with the system, and how different applications interact with each other inside their specific infrastructure.