The Principle of Least Privilege encourages us to restrict software components to access only the resources that they need. By default, however, a Linux process can do anything its running user can do—from binding to arbitrary ports to spawning new shells. The Linux Security Modules (LSM) framework, which allows for security extensions to be plugged into the kernel, has been used to implement MAC on Linux. SELinux and AppArmor are the predominant and best-known LSM-compatible implementations that ship with the kernel. We recommend that teams learn to use one of these security frameworks (which is why we placed it in the Adopt ring). They help teams assess questions about who has access to what resources on shared hosts, including contained services. This conservative approach to access management will help teams build security into their SDLC processes.
Application whitelisting has proven to be one of the most effective ways to mitigate cyber intrusion attacks. A convenient way to implement this widely recommended practice is through Linux security modules. With SELinux or AppArmor included by default in most Linux distributions, and with more comprehensive tools such as Grsecurity readily available, we have moved this technology into the Adopt ring in this edition. These tools help teams assess questions about who has access to what resources on shared hosts, including contained services. This conservative approach to access management will help teams build security into their SDLC processes.
In earlier versions of the Radar, we have highlighted the value of Linux security modules , talking about how they enable people to think about server hardening as a part of their development workflow. More recently, with LXC and Docker containers now shipping with default AppArmor profiles on certain Linux distributions, it has forced the hand of many teams to understand how these tools work. In the event that teams use container images to run any process that they did not themselves create, these tools help them assess questions about who has access to what resources on the shared host and the capabilities that these contained services have, and be conservative in managing levels of access.
While server hardening is an old technique that is considered fairly commonplace by sysadmins who have had to manage production systems, it has not become commonplace among the developer community. However, the rise in the DevOps culture has resulted in renewed focus on tools like SELinux, AppArmor and Grsecurity that aim to make this simpler, at least on the Linux ecosystem. Each of these tools comes with their own strengths and weaknesses and it is currently hard to pick one as being the only one you will need. That said, we highly recommend that all teams at least assess which Linux security modules would be the right one for them and make security and server hardening a part of their development workflow.
