Capabilities
Capabilities
Everything related to Linux capabilities, like articles and an overview of the available capabilities.
Summary
ProtectHome setting
Restrict systemd units to access data in home directories with the unit setting ProtectHome.
Summary
Why and when to use ProtectHome
The setting ProtectHome aims to protect home directories. These three paths are included:
- /home
- /root
- /run/user
Settings
The default no will not restrict access to the home directories. Using yes will active full protection, not allowing access.
The value read-only will make the paths read-only, so no data can be written to it.
With tmpfs a temporary file system is being used, also read-only, yet it hides the actual home directories. It will still allow access to the actual directories when using BindPaths or BindReadOnlyPaths. For rare situations this might be useful to protect the home directories, while still allowing some very specific access.
ProtectKernelLogs setting
Restrict systemd units to read or write to the kernel log ring buffer with the unit setting ProtectKernelLogs.
Summary
Background
The Linux kernel exposes its kernel log ring buffer to userspace via /dev/kmsg and /proc/kmsg.
When this setting is defined as yes, the capability CAP_SYS_MODULE will be removed from the capability bounding set. This means that all processes in the unit will no longer have access to the kernel log ring buffer.
ProtectKernelModules setting
Restrict systemd units to load kernel modules with the ProtectKernelModules unit setting.
Summary
Explanation
Kernel modules can provide additional functionality when using a modular Linux kernel, which is applicable to most systems. When this setting is set to yes, it tries to prevent the unit from loading kernel modules. This is achieved by removing the CAP_SYS_MODULE from the capability bounding set.
Generic advice
Most units do not need the permission to load kernel modules, so typically a unit can be configured with ProtectKernelModules=true.
Docker Security: Best Practices for your Vessel and Containers
In-depth article about Docker security features, best practices and its history. With container technology evolving, Docker security can be challenging..
Summary
Everything you need to know about Docker security.
Introduction into Docker
Docker became very popular in a matter of just a few years. Operating systems like CoreOS use Docker to power the system by running applications on top of their own lightweight platform. Docker in its turn, provides utilities around technologies like Linux container technology (e.g. LXC, systemd-nspawn, libvirt). Previously Docker could be described as the “automated LXC”, now it’s actually even more powerful. What it definitely is, is simplifying and enhancing the possibilities of container technology.
Linux capabilities 101
Introduction guide and tutorial about the inner workings of Linux capabilities and how these capabilities are applied when running Linux processes.
Summary
Security of Linux systems and applications can be greatly improved by using hardening measures. One of these measures is called Linux capabilities. Capabilities are supported by the kernel for some while now. Using capabilities we can strengthen applications and containers. Unfortunately, this powerful tool is still underutilized. Time to change that! This article helps to understand and apply them.
What are Linux capabilities?
Normally the root user (or any ID with UID of 0) gets a special treatment when running processes. The kernel and applications are usually programmed to skip the restriction of some activities when seeing this user ID. In other words, this user is allowed to do (almost) anything.
Linux Capabilities: Hardening Linux binaries by removing setuid
Setuid binaries may be a risk for the system. We will investigate how to remove the setuid bit and use Linux capabilities instead, to reduce the risks.
Summary
Hardening Linux binaries by removing setuid
Normally Unix based systems use two kind of processes: privileged and unprivileged. The first category is usually used for administrative purposes, like starting and stopping other processes, tuning the kernel and opening sockets.
Root permissions
The command ping is a great example why even small programs needs root permissions. In a first glance you might consider this tool to be simple: send a package to a host and see if it responds. The truth is that a network socket needs to be opened, to send an ICMP package.
How and why Linux daemons drop privileges
By dropping privileges a process can be better protected against attacks. Learn how this applies to Linux systems and software.
Summary
In this article we have a look at the privileges of Linux daemons and dropping privileges in particular. The samples provided are in C.
Why drop privileges?
Some daemons need root permissions to start. This happens for example when a daemon wants to bind to a low port (<1024). However running network based daemons with root permissions is considered to be a serious risk. In case of compromise of the process, an attacker has full access to the system. This is why software like nginx starts with a master process and forks non-privileged child processes. These child processes (or workers), run under the context of non-privileged account like www-data.