anitsh
commented
3 years ago Linux Capabilities
- [ ] What is it?
- [ ] How Linux Capability Works?
Capabilities break up root privileges in smaller units, so root access is no longer needed. Most of the binaries that have a setuid flag, can be changed to use capabilities instead. They are maintained by the kernel.
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.
Capabilities are a great way to split up root permissions and hand out some permissions to non-privileged users. Unfortunately, still many binaries have the setuid bit set, while they should be replaced with capabilities instead.
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 provide a subset of the available root privileges to a process. This effectively breaks up root privileges into smaller and distinctive units. Each of these units can then be independently be granted to processes. This way the full set of privileges is reduced and decreasing the risks of exploitation.
Capabilities can be thought of as broad classes of privileged functionality that can be selectively removed from a process or user. The specific functions that have capability checks vary from kernel version to kernel version, and there is often bickering between kernel developers over whether or not a given function should require capabilities to run. Generally, reducing capabilities from a process improves security by reducing the number of privileged actions it can perform. Note that some capabilities are considered root-equivalent, meaning that, even if you disable all other capabilities, they can, in some conditions, be used to regain full permissions.
cat /proc/sys/kernel/cap_last_cap # See the highest capability number for your kernel. The number of capabilities supported by recent Linux versions is close to 40.
# View list of available Linux capabilities for the active kernel.
capsh --print
# View current user's capabilities. Command should return 5 capabilities with hexadecimal numbers.
cat /proc/{HIGHEST_CAPABILITY_NUMBER}/status | grep Cap
# CapInh = Inherited capabilities
# CapPrm = Permitted capabilities
# CapEff = Effective capabilities
# CapBnd = Bounding set
# CapAmb = Ambient capabilities set
# Decode hexadecimal number into the capabilities name.
capsh --decode=0000003fffffffff
# See the capabilities of a running process.
# getpcaps tool uses the capget() system call to query the available capabilities for a particular thread. This system call only needs to provide the PID to obtain more information.
getpcaps PROCESS_ID
# See the capabilities of a set of processes that have a relationship.
getpcaps $(pgrep nginx)
# Drop ping capability.
capsh --drop=cap_net_raw --print -- -c "/bin/ping -c 1 localhost"
Resources
- [x] https://linux-audit.com/linux-capabilities-101
- [ ] http://linux-audit.com/linux-capabilities-hardening-linux-binaries-by-removing-setuid
- [ ] How_Linux_Capability_Works.pdf
- [ ] https://opensource.com/business/15/3/docker-security-tuning
- [ ] https://www.redhat.com/sysadmin/privileged-flag-container-engines
- [ ] https://linux.die.net/man/7/capabilities
- [ ] https://www.hackingarticles.in/linux-privilege-escalation-using-capabilities
- [ ] https://man7.org/linux/man-pages/man2/prctl.2.html
- [ ] https://www.cyberciti.biz/tips/linux-advanced-hardening.html
- [ ] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/linux_capabilities_and_seccomp
- [ ] https://www.kernel.org/doc/htmldocs/lsm/index.html
Linux Security Infrastructure
In a normal operating system (OS), every application is unmonitored and it is difficult to determine what is happening in a system.
'''Enforcing security goes in hand with knowing what you are protecting yourself against, or at least what you are protecting. All that, however, must start with a security policy. Once the policy is formulated, the choice is easier to make. Let's consider a few cases, which may or may not reflect your use cases. But before considering them, it may be helpful to narrow down the available options to the following:
And now, the cases: I want to run a program in a way that is immune to malicious exploitation: since that means any attack, known or unknown, nothing is guaranteed to satisfy your requirement (every security framework should tell you this). But at least, restricting your program to the fewest possible system calls reduces its attack surface, although you can still be attacked from anywhere even if it's a 1% of the possible ways. However, if stripping privileges off applications to make them less useful to the attacker, system call filtering and capability systems will be helpful. Seccomp (available on Linux), Capsicum (available on FreeBSD, and soon on Linux), and POSIX capabilities are options here. I want to restrict my programs to known/expected behavior: easy (for simple programs) - if you can define runtime behavior in terms of accessed files or kernel objects, then MAC frameworks can help you (AppArmor, SELinux, ...). However, you will also have to make choices as to what level of abstraction you want to express your policies, so preciseness and flexibility will be pulling you in different directions (are paths precise enough, are inodes manageable for you, what about memory segments?). I often find myself needing to run programs with elevated privileges and worry it may be too risky: we've all been there. Dropping capabilities is probably the most reasonable option. It is OS-specific (and so are all the others), but at least implementation-independent if done as part of access control on a given machine (as opposed to invoking the capabilities interface programmatically, which will depend on available bindings in your language).'''
Linux Security Modules (LSM)
Linux Security Modules (LSM) is a framework that allows the Linux kernel to support a variety of computer security models while avoiding favouritism toward any single security implementation. AppArmor, SELinux, Smack, and TOMOYO Linux are the currently accepted modules in the official kernel.
Mandatory Access Control (MAC)
A type of access control by which the operating system or database constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target.[1] In the case of operating systems, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices, etc. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object is tested against the set of authorization rules (aka policy) to determine if the operation is allowed. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc.
With mandatory access control, this security policy is centrally controlled by a security policy administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes. (The traditional Unix system of users, groups, and read-write-execute permissions is an example of DAC.) MAC-enabled systems allow policy administrators to implement organization-wide security policies. Under MAC (and unlike DAC), users cannot override or modify this policy, either accidentally or intentionally. This allows security administrators to define a central policy that is guaranteed (in principle) to be enforced for all users.
Mandatory Access Controls
A MAC is a framework for defining what a program can and cannot do, on a whitelist basis. A program is represented as a subject. Anything the program wants to act on, such as a file, path, network interface, or port is represented as an object. The rules for accessing the object are called the permission, or flag. Take the AppArmor policy for the ping utility, with added comments:
With this policy in place, the ping utility, if compromised, cannot read from your home directory, execute a shell, write new files, etc. This kind of sandboxing is used for securing a server or workstation. Other than AppArmor, some popular MACs include SELinux, TOMOYO, and SMACK. These are typically implemented in the kernel as a Linux Security Module, or LSM. This is a subsystem under Linux that provides modules with hooks for various actions (like changing credentials and accessing objects) so they can enforce a security policy.
Discretionary access Control (DAC)
A type of access control defined by the Trusted Computer System Evaluation Criteria[1] "as a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control)".
Discretionary access control is commonly discussed in contrast to mandatory access control (MAC). Occasionally a system as a whole is said to have "discretionary" or "purely discretionary" access control as a way of saying that the system lacks mandatory access control. On the other hand, systems can be said to implement both MAC and DAC simultaneously, where DAC refers to one category of access controls that subjects can transfer among each other, and MAC refers to a second category of access controls that imposes constraints upon the first.
Kernel Security Tools
OR
Other
Chrooting bash, for example, would involve putting any executables and libraries it needs into the new directory, and running the chroot utility (which itself just calls the syscall of the same name):
Only a process with the CAP_SYS_CHROOT capability is able to enter a chroot. This is necessary to prevent a malicious program from creating its own copy of /etc/passwd in a directory it controls, and chrooting into it with a setuid program like su, tricking the binary into giving them root.
Based on what they do:
Overall, these products can be grouped into ones focused on enforcement vs auditing. Both groups define a policy that describes the allowed or disallowed behavior for a process, in terms of system calls, their arguments, and host resources accessed. Enforcement tools use the policy to change the behavior of a process by preventing system calls from succeeding, or in some cases, killing the process. Seccomp, seccomp-bpf, SELinux, and AppArmor are examples of enforcement tools. Auditing tools use the policy to monitor the behavior of a process and notify when its behavior steps outside the policy. Auditd and Falco are examples of auditing tools. (Falco does allow taking actions on alerts via its command execution notification channel, so it has limited enforcement capabilities, but it is not intended to be used as an enforcement tool).
Sandboxing
At its most basic, sandboxing is a technique to minimize the effect a program will have on the rest of the systems in the case of malice or malfunction. This can be for testing or for enhancing the security of a system. The reason one might want to use a sandbox also varies, and in some cases it is not even related to security, for example in the case of OpenBSD's systrace. The main uses of a sandbox are:
There are many sandboxing techniques, all with differing threat models. Some may just reduce attack surface area by limiting APIs that can be used, while others define access controls using formalized models similar to Bell-LaPadula or Biba.
Resource
Related: #112 #427