6

I am trying to understand various options I have to restrict/sandbox a binary in Linux. I see that I can use namespaces and cgroups like docker does. I could use SELinux like this link suggests. Which one do I use? Are namespaces and cgroups implemented using SELinux? How do these coexist in Linux?

Also when do I use capabilities? Why would I need those if I have either SElinux or namespaces/cgroup policies built into the binary?

Jakuje
  • 20,974
  • 7
  • 51
  • 70
user220201
  • 161
  • 1
  • SELinux has many possibilities to fit your needs, but it is not available on all linux distros. As an alternative, I can recommend `seccomp filter` – Jakuje Aug 07 '15 at 07:19
  • I am more trying to understand the difference between SELinux and namespaces/cgroups. So from your response I gather that they are completely orthogonal systems. – user220201 Aug 07 '15 at 07:28
  • Basically yes. They are independent. You can use both of them (as Docker does under some conditions), but I am not so much experienced in this topic so I would wait for another answers. I just wanted to point out another possibility to limit process access rights. SELinux is certainly not compiled into binary, but `seccomp` is. – Jakuje Aug 07 '15 at 07:41

1 Answers1

1

Linux contains multiple different security mechanisms which can be used to place restrictions on processes. Most of them can be used together to build sandboxes and containers. A very short overview of some of the mechanisms:

  • DAC (discretionary access control): the traditional owner/group permissions. Process owner, group(s), traditional permission bits on files.

  • MAC (mandatory access control), SELinux and AppArmor being the most common implementations. MAC systems enforce rules between subjects (processes, users, ...) and objects (files, sockets, ...) to decide allowed access. MAC rules make sophisticated policies and finer grained permissions possible. However the configuration can be a non-trivial amount of work.

  • capabilities allow a process to hold a subset of superuser's privileges. A process executed as root can retain certain capabilities before switching to non-privileged user, thus hopefully reducing attack surface by retaining only the minimum amount of superuser capabilities. However many capabilities are very broad and can be almost equal to root[1]. Some setuid binaries can be made non-setuid by using file capabilities instead.

  • cgroups are used for process accounting, applying resource limits and management. For example freezer provides a reliable way to freeze all processes within the group (which can otherwise be a problematic task).

  • namepsaces allow process' to have separate environments (mount, network, user, pid, ...). Network namespaces do not share same network configuration, each pid namespaces are not aware of PID of its parent, and so on. It is rather easy to see how namespaces can be used to build a Linux container.

(and there are more mechanisms, such as chroots, seccomp filters and ACLs.)

Some of the features are overlapping (such as DAC, MAC and capabilities). Using them together can still be useful in building layered security. A vulnerability due to a bug or misconfiguration ideally is mitigated in one of the layers.

Each feature includes its own utilities and APIs. LXC provides an easy way to take advantage of these features via single interface. LXC also allows configurations which use only some of the features; for example sharing mount namespace with host while having a private network namespace. It is also possibly to run a complete Linux userspace inside a container having its own separate namespaces.

sebasth
  • 14,332
  • 4
  • 50
  • 68