Is Linux as Secure as We Think?

Linux is considered more secure than Windows, but it has its fair share of vulnerabilities, such as the Sudo vulnerability and other Linux weaknesses. Amid growing cloud adoption, we look at the steps security teams should take to defend Linux against cyberattacks. 

To understand Linux security one must understand Linux kernel as many of the existing and emerging attacks are against the Linux kernel. As shown in Figure 1, the kernel is the core of any Linux release. Further, the same kernel is used in all Linux distributions. Differences in distribution vulnerabilities exist because not all distributions use the same version of the kernel. 

Figure 1: Linux System

The kernel controls all operations on a Linux platform, including access controls. Gaining control of the kernel can result in complete control of the platform on which it is installed.

The general configuration of Linux is much different from Windows, and it has traditionally been considered more secure. However, the increasing use of Linux is making it a bigger target. Since the kernel is common to all releases of the OS, it is a popular focus of Linux attacks.

Learn more: How To Pick the Best Security Framework for Your Organization

Linux Kernel Vulnerabilities

Kernel vulnerabilities occur for two primary reasons: mistakes in coding and misconfiguration.

Vulnerabilities

Qualys discovered two kernel vulnerabilities this month: CVE-2021-33909 and CVE-2021-33910. Because the kernel is used widely, Red Hat, Debian, Ubuntu, and SUSE confirmed the presence of 33909 in their distributions. The vulnerability enables a threat actor with user privilege to gain access to out-of-bound memory.

In April 2021, Tara Seals reported that CVE-2020-28588, an information disclosure vulnerability, allowed unauthorized access to data because of “…improper conversion of numeric values when reading [a] file.”

Some of the earlier vulnerabilities in Linux include: 

• Heartbleed (CVE-2014-0160): Allowed the extraction of keys or other information due to failure to check OpenSSL return payloads.
• Spectre and Meltdown (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754): Enable reading of memory running on the local device.
• SACK Panic and Slowness (CVE-2019-11477, CVE-2019-11478): Exploits the kernel’s TCP, which can result in denial of service.

Some vulnerabilities can be repaired without patching. For example, Heartbleed is fixable before patching by recompiling OpenSSL with a specific parameter. Others like Spectre and Meltdown require patching.

All software, including operating systems, contain vulnerabilities. The complexity of the code resists complete elimination of execution risk, regardless of the OS.

Misconfigurations: Lack of Hardening

When configured appropriately, Linux is a very secure OS, but very secure does not mean risk-free. As with Windows, how Linux is configured can affect the permeability of its attack surface. In the videoOpens a new window on System Hardening, I described general steps engineers should take to ensure the secure configuration of any servers, including

• Shutting down all unused ports and services
• Encrypting data
• Managing penetration test results
• Reviewing and testing code
• Segmenting the network
• Securing communication
• Removing or locking default passwords
• Limiting servers to a single function
• Removing all unnecessary software and utilities
• Managing and auditing privilege account access

Learn more: Top 10 Linux Firewall Solutions in 2021

Linux Security Capabilities

While we cannot completely rid Linux distributions of vulnerabilities, we can build security walls around the potential impact when threat actors exploit those weaknesses.

PAM

One set of safeguards that come with most Linux distributions are pluggable authentication modules (PAM). PAM provides centralized authentication management for applications and services that are PAM-aware. Any additions or changes to account login policies are made to the configuration file with the same name in /etc/pam.d.

Figure 1 is based on the PAM articleOpens a new window by Susan Lauber. PAM’s collection of configuration files stored in /etc/pam.d are used to implement biometrics and other authentication methods and conditions for any PAM-aware application or service. Authentication granularity is enabled with additional configuration files located in /etc/security. 

Figure 2: PAM Operation

SELinux

SELinux is a Linux security enhancement that enables mandatory access control (MAC). This is a significant improvement over the traditional discretionary access control (DAC) that shipped with early versions of Linux, and it is still the default method used by the kernel security framework. When using DAC, “…a process can access any file, directory, device, or other resource that leaves itself open to access” (Christopher Negus, “Linux BibleOpens a new window ”). 

MAC enforcement with SELinux controls access by explicitly defining the resources to which a process has access. This is managed by applying business policies to processes that restrict access by managing capabilities like read and write. This approach helps prevent compromised kernel processes from maliciously accessing sensitive information.

According to the openSUSE Security and Hardening Guide, implementing SELinux requires labeling objects and processes. These labels establish privilege boundaries. Implementation includes:

• Linux kernel security framework
• SELinux libraries and binaries
• SELinux policy

The SELinux policy drives protection. However, organizations do not have to start from a blank policy. The SELinux Reference Policy ProjectOpens a new window provides a complete policy as a foundation.

Learn more: Windows 11 Roundup: The Top Productivity and Security Features in Microsoft’s New OS

Role of Segmentation 

Linux is just not on servers. Embedded Linux is also spread across Internet of Things (IoT) and industrial IoT (IIoT). Implementing server hardening, PAM, and SELinux on these devices is not usually possible. Consequently, IoT and IIoT must be segmented from the rest of the production network.

As I wrote in Securing Industrial Control Systems From Modern Cyber Threats, IoT and IIoT should not be directly accessible by the internet or on-premises networks. In addition, IoT and IIoT segments should not have unfiltered access to cloud and on-premises data and processes. Figure 2 shows the Gartner IoT Reference Architecture discussed in my industrial control systems article.

Figure 3: Gartner IoT Reference Model

Final Thoughts

Linux is a reasonably secure operating system, but it is not perfect. Some access control risks still exist due to 

• Coding errors 
• Lack of device hardening
• Failure to configure available authentication and access control capabilities
• Failure to segment embedded Linux devices.

Another concern is the commonly held belief that Linux systems do not require anti-malware and other safeguards surrounding Windows servers. This is dangerous. As the number of Linux servers (both virtual and physical) increases, they become a more lucrative target for threat actors. Consequently, cybercriminals will spend more time identifying ways to compromise Linux resources.

Implementing the controls as suggested in this article and additional safeguards in Linux hardening best practices, like those contained in Red Hat’s Linux security guideOpens a new window , are needed. These are often not easy to implement, so organizations must ensure proper hiring and training of Linux engineering staff to meet the challenges. 

Do you think Linux attacks have increased because of the growing use of Linux resources? Comment below or let us know on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!