User:SwifT/selinux-tutorials/1

The security context of a process
When working on a Linux system, you are undoubtedly aware that there are processes running all around. Processes (sometimes also referred to as tasks) are generally speaking applications that are running. For instance, on a booted Linux system, you might find processes such as sshd (the OpenSSH daemon, used to provide secure remote shells towards the system), crond (the Cron daemon, used to run certain commands at predefined time(intervals)) or udevd (the device handling daemon, which receives kernel events and acts on those towards the system), but also user processes like bash (a user shell), xinit (the graphical X server session application) or even ps (the command to show running processes).

Processes on Linux
From a process listing, more advanced administrators will be able to tell you what each process is (supposed to be) doing. This is because these processes have names that are known to match a given application - sshd is the secure shell daemon.

In the above example, two processes are listed. The first one is the user shell (where bash stands for Bourne Again SHell) and most likely the shell that the user is currently working in, i.e. the application in which he just typed ps) and the second one is the ps application (short for processes, the application that is showing the output of the running processes). Of course, many more are running on a Linux system, but without additional arguments to the ps command, it only outputs the applications running within the current session of the user.

Let's take a look at a few other processes. In the next command, we ask for all running processes on the system (-e) with additional information (-f), but limit the output to those processes that have auditd and sshd in their name. We'll run this as the root Linux user, since some hardened Linux systems do not allow regular users to view processes of other users.

In this example, we notice four processes in the output:
 * 1) the auditd process, which is the Linux audit daemon (responsible for handling audit events and writing them to the audit log files)
 * 2) the kauditd kernel process, which is a part of the Linux kernel responsible for the kernel audit events (and communicates with the auditd process). The special brackets surrounding it are telling you that this is not a regular (userland) process (launched through a command), but a kernel process (started/managed by the Linux kernel itself)
 * 3) the sshd secure shell daemon
 * 4) the grep command we just used to filter the output of the previous command

Now, although seasoned administrators are well able to tell you what these processes are (supposed to be) doing, they will also tell you that these processes are all running as the Linux root user, the all-powerful administrator account on Unix and Linux systems. And because of that, all these applications have the same powers over the system as the root user does.

Privileges of processes
As long as applications behave as they should, and users are not abusing the applications, then having them run as root is okay. And although root-running applications have all the powers of the root user, because they are written with a few tasks in mind (how difficult is it to write an audit daemon, or a secure shell daemon, with no bugs in, right?) they are often seen as sufficiently trustworthy to run on a system.

But then comes in the evil, malicious person. A user with little to no specific privileges on the system (a regular user account, or perhaps not even an account at all) who is trying to interact with one of these root-running processes in a way that these applications suddenly misbehave and give the user root access (privilege escalation in case the user was running as a non-privileged account and now holds root privileges) or allows the user to launch commands through the root-running process (remote command execution).

Bugs in applications that allow such attacks are called vulnerabilities and are not new to administrators and engineers. Even for applications closely developed for security purposes, such as the audit daemon or secure shell daemon, such vulnerabilities arise from time to time. An example would be CVE-2008-1628 where the Linux audit daemon (version lower than 1.7) has a vulnerability that could potentially lead to code execution (and thus privilege escalation). An important aspect of system security is thus to keep track of security updates - do not allow your system to run old software versions that are known to be vulnerable to one or more exploitable bugs. Or even better, don't run old software. Period.

But constantly upgrading your software still doesn't protect the system from being attacked. Software might be vulnerable without a fix at hand (for instance in case of 0day exploits, where the vendor or developer of the software is not yet or just very recently been made aware of the vulnerability, and has not had the time to update its software) or the fix might not have been packaged by your Linux distribution yet. And in some companies, security fixes, even when released by the distribution, take weeks or even months to be pushed out to the production systems.

One of the core problems at hand are the privileges of the process that is being attacked. Applications that run as root are prone to be attacked in the hope to get root access on the system (and thus be all powerful). Because of this, application engineers have been using various methods to lower the privileges under which the application is running.


 * Some applications use a split process setup, where one very small application runs as root (because it needs to, for instance to bind on a TCP or UDP port lower than 1024, or to access certain system resources) and the other one runs as a non-root user. The non-root running application is the main application and attempts to securely communicate with the first process. This way, the likelihood that a vulnerability is found in the (small) root-running process is lowered.
 * Some applications use Linux capabilities and drop the capabilities that they don't need. Capabilities are one way of reducing root privileges, but are not in scope of this tutorial set.
 * Some applications don't run as root - period. A relational database such as postgresql or mysql is developed to run as its own, dedicated (non-root) user. As a result, vulnerabilities in these applications are less likely to result in total system compromise, although the databases themselves are still compromised.