Skip Navigation

Assignment 7: Explore Software Complexity

For this assignment, you will explore the idea that a larger, more complex piece of software naturally yields a larger attack surface than a smaller, more contained piece of software. As a case study, you will look at the controversial systemd software layer that is present on most Linux systems.

Page Contents

Background Material

Developers tend to acknowledge that the number of bugs in a program increases with the number of lines of code, since code typically has a measurable defect ratio that relates to code length. Since this ratio is greater than zero, simple multiplication results in the conclusion that more code yields more bugs. Certain kinds of bugs in code are more dangerous to security, since they tend to create vulnerabilities in the finished application. It stands to reason that if these dangerous kinds of bugs make up some measurable (but nonzero) proportion of all bugs, then the risk of a piece of software increases with the number of lines of code used to implement that software. Put another way, more code yields a larger attack surface, since there are likely to be more defects that can be exploited.

Finding and fixing bugs in software can become quite challenging as the sheer size of the code base increases. It is not reasonable for a single human being to review a million lines of code, as doing so would likely take more than one human lifetime. In addition, the complexity of the code may be such that relatively few people understand what the code actually does. This observation is especially true for code that is tightly coupled to other code, meaning that it has a lot of interdependencies with that other code. In addition, code that has low cohesion also tends to be more complex for the simple reason that low-cohesion code tends to be doing a lot of different, unrelated things. For some time now, software engineers have promoted a model of loosely coupled, highly cohesive components that are each easier to understand and debug in isolation.

A real-world example of a huge code base that has both tight coupling and low cohesion can be found in systemd, which is a service management layer that has been adopted by the vast majority of Linux distributions. The code base for systemd passed the 1.2 million line mark in 2019. This software has low cohesion, since it is performing a bunch of unrelated tasks in addition to managing system services. The systemd executable is compiled from all the millions of lines of code that make up its sources, and the resulting systemd binary occupies a privileged position in the Linux software stack. Specifically, it is the first program started by the Linux kernel at boot time and remains active for the entire time that the computer is up and running (known as “PID 1” in Linux system administrator speak). Furthermore, systemd runs with root privileges, meaning that it has unlimited authority to change hardware settings, read and write files, and perform any other task that the system administrator could otherwise do.

Consider the gravity of this one application. It has many lines of code, meaning that it likely contains quite a few bugs. Some proportion of those bugs are exploitable, and any exploits have full privileges to take control over the entire system. These vulnerabilities are not merely theoretical, as demonstrated by CVE-2021-33910, CVE-2022-2526, and so forth.

Given the obvious risks of allowing such a large code base to run as a highly privileged process, one might ask why so many Linux distributions have adopted systemd. The reason really boils down to convenience for distribution maintainers, since systemd dictates certain design choices and automates many of the tasks that distribution maintainers would otherwise have to do by hand. An excellent summary can be found in a post explaining systemd adoption in Arch Linux. One could also argue that multiple distributions using systemd makes Linux system administrator knowledge more portable, since the commands to manage services will be the same across systems. Prior to the widespread adoption of systemd, one of the major distinguishing features of different Linux distributions involved the ways that services were started, stopped, and monitored.

Of course, like everything in the computing discipline, there is always a trade-off. In this case, the trade-off to create less work for distribution maintainers and a more common set of tools for system administrators comes at the cost of potential vulnerabilities that are both deep and widespread. The worst-case scenario would be for a zero-day exploit to be developed for an unknown systemd vulnerability, which would enable an attacker to compromise the vast majority of Linux servers on the planet – which, in turn, means compromising the vast majority of Internet websites (most of which run on Linux servers). On the other hand, the same argument can be made about a zero-day exploit on the Linux kernel itself, which leaves room for spirited debate on the relative pros and cons of systemd as part of the Linux software stack.

Rather than trying to summarize this debate, it is more useful to link to some of the better criticisms of systemd:

Of course, for every criticism there are counter-points:

Initial Post Requirements

Consider the above background material and take a position as to whether you think the benefits of systemd outweigh the potential security risks. You may take either position in favor or against. In considering your position, think about the following:

Formulate an initial discussion post as a narrative that considers these questions and takes a position as to whether or not systemd is worth the risks to obtain its benefits. Cite at least one source (which may come from the background material or your own research) to support your position.

As a reminder, you must do your own writing. Use of ChatGPT or other artificial intelligence tools is NOT PERMITTED, beyond the use of the automated word completion and grammar checking that may be available in Microsoft Teams.

Completion Standards

A complete initial post for this assignment:

  1. Articulates potential vulnerabilities of running a large code base as a privileged process.
  2. Compares the complexity of systemd against alternatives.
  3. Takes a position as to whether or not the convenience of systemd exceeds its security risks.
  4. Cites at least one source. Citations may be informal – a link is sufficient.

There are no word limits or targets (minimum or maximum), but try to make the post both complete and concise.

Assessment

Successful completion of this assignment satisfies the following course student learning outcome: