Mini-Project 3: Systems Security #

The goal of this project is to gain practical experience with least-privilege access control policy. Specifically, you will be exploring the sandbox permissions provided by Flatpak, an emerging package distribution format for Linux desktop applications. The project emphasizes security and usability trade-offs, as well as the importance of policy specification when creating a secure system.

Points: Mini-Project 3 has a maximum of 100 points with an additional 10 points for extra credit.

Due: Mini-Project 3 is due on Fri, Nov 8 - 11:59pm .

Collaboration:

• You may not collaborate on this mini-project. The project should be done individually.
• You may search the Internet for help, but you may not copy (either copy-and-paste or manual typing) code from another source without proper attribution.

Posting Solutions: You are explicitly forbidden from posting your solution in a public form (e.g., GitHub). If you need to share your solution as part of a job interview, you should create a private repository and grant that individual access. Please ask the instructor if you have any questions or concerns.

Submission #

What to submit: This assignment should be submitted to GradeScope. The submission should include a PDF document that provides your written answers to the questions for each part.

Introduction and Setup #

The Linux desktop is fraught with fragmentation, complicating software distribution and installation. As a response, Flatpak, Snap, and AppImage have emerged as distribution-independent ways to package software. Of these formats, both Flatpak and Snap incorporate mechanisms to sandbox applications, much in the same way that Android and iOS treat applications as distinct security principals. In this mini-project, we will be exploring Flatpak’s sandbox permissions. If you are interested, you are encouraged to explore Snap permissions on your own. Unfortunately, building Snaps within virtual machines proved more difficult than desired for this project.

You need a Linux distribution to complete this mini-project. I recommend using VirtualBox to set up a virtual machine running the latest version of Fedora workstation (Note: Fedora 41 and later requires manual installation of X11 components for Part 2). You may also use VMWare or GNOME Boxes. If you have an Apple Silicon Mac, use UTM instead. Be sure to download the aarch64 disk image instead of the x86_64 disk image if you are using UTM. Even if you are already using a Linux desktop, you may wish to install a fresh virtual machine for this assignment, because one of the parts will require you to be logged in with an X11 window session, which is less secure than Wayland.

Note: If you are running Ubuntu, some parts of this assignment may not make sense due to the integration of Snaps into Ubuntu. Therefore, I recommend not using Ubuntu for this assignment and instead, e.g., installing a Fedora VM.

Note: If you are having trouble creating the VM on your computer, contact the TA.

Part 1: Exploring Flatpak Permissions #

(25 points)

Read this basic introduction to Flatpak. Setup the Flathub Flatpak repository on your system. Next, install five to ten Flatpak applications from Flathub. You can browse the Flathub repository to find Flatpaks available for your system. Experiment with installing Flatpaks from the GNOME Software center and via the command line. If a package is available both from the OS (e.g., dnf) and as a Flatpak, there will be a “Source” dropdown in the top right hand corner (see below). You can confirm that a Flatpak has been successfully installed by executing flatpak list in the command line.

Question 1.1 #

(5 of the 25 points)

Communicating security protections to users is extremely important. The above table shows both the old installation GUI (from Fedora 33) and the new installation GUI (from Fedora 35) in the GNOME Software Center. Click the screenshots to enlarge the image.

Part A: First, consider only the old installation GUI. Notice the “Sandboxed” icon listed under “Details” in the above screenshot, as well as when you install Flatpaks on your system. If you were to change the “Source” to the default for your OS (e.g., RPM), the the “Sandboxed” icon is no longer highlighted. Describe your security expectations for installing an application that is “Sandboxed” verses one that is not “Sandboxed”.

Part B: Now look at the screenshots for the new installation GUI. Have your expectations changed? If so, how? If not, why not?

Question 1.2 #

(20 of the 25 points)

Read the documentation for Flatpak sandbox permissions as well as the permissions reference. Next, install Flatseal, which provides a graphical interface for exploring the Flatpak packages you have installed.

For 5 applications (4 points each), list the application along with the permissions it has. Discuss whether or not you think the permissions are appropriate. You may install additional applications if your original 5–10 applications do not have interesting sandbox policies.

Special: If your environment looks like the “New Installation GUI” above, note differences in your expectations when viewing the permissions in the installation GUI from what you are able to see with Flatseal.

Part 2: The (in)security of X11 #

(25 points)

X11 has been the de facto windowing system on Unix platforms since the early 1980s. As with many technologies created in the 1980s, X11 was designed for functionality and performance. Security was a secondary consideration. As a result, X11 is terribly insecure (we will demonstrate one way in this part). It is being replaced by Wayland, which is both simpler and more secure. However, the transition from X11 to Wayland will be long and slow, requiring changes within applications. While Xwayland provides a compatibility interface to run X11 applications in Wayland, applications using enhanced features of X11 (e.g., screen sharing) require explicit code changes. Therefore, many Linux distributions ship with X11 as the default window system. Even as distributions switch to Wayland, many users will likely revert to X11 for application compatibility.

One of the (many) insecure aspects of X11 is the ability to perform keylogging. The xspy command is a classic way to log every character typed into any application. However, you can also accomplish keylogging using a one-line shell command that wraps the built-in xinput command.

Note: Fedora 41 has deprecated X11. If you installed Fedora 41 or later, you will need to manually install the necessary packages to complete this part (sudo dnf install gnome-session-xsession should work, but has not been tested).

Question 2.1 #

(20 of the 25 points)

Create a Flatpak that uses X11 to eavesdrop on the keyboard entry of other applications outside of its “sandbox”. Note that to be successful, you must be logged into an X11 window session, which can be selected from the GNOME login window (look for the gear in the bottom right hand corner). You can confirm you are running X11 by executing echo $XDG_SESSION_TYPE.

Start by following the instructions to build and install a “Hello World” Flatpak application. Similar to the hello.sh script used for the “Hello World” application, you can create a keylogger.sh script to wrap xinput as described on techtrickery.com. Name your Flatpak application org.flatpak.keylogger.

1
2

#!/bin/bash
xinput test $(xinput list | grep 'AT Translated' | sed 's/.*id=\([0-9]*\).*/\1/')

Note that since Flatpaks are largely self-contained, you will need to build xinput into the application during the Flatpak build process.

Furthermore, note that xinput does not show the actual character that is pressed. You can use xmodmap -pke >> keyboard.txt to find the mapping. Include in your Flatpak a script to wrap the output of xinput and convert it to characters.

In your PDF report, include the following:

• A screenshot of the keyboard logger to demonstrate it works.
• The complete keylogger script including the xinput character converter. Please include this within the PDF report itself.
• Your org.flatpak.keylogger.yml Flatpak configuration file. Please include this within the PDF report itself.

Important: You must be logged into the X11 windowing environment for the keylogger to work (confirm by executing echo $XDG_SESSION_TYPE).

Hint: xinput must be built from source as part of the Flatpak build process. Copying the system xinput executable into the Flatpak will not work as the sandbox will prevent the application from linking with system library files. You can include the xinput GitLab repository as a module in your manifest file to bundle it into the Flatpak.

Hint: If you are having trouble creating your Flatpak manifest file, you can check out some examples of real applications from Flathub. The build files for every application on Flathub are available via the Flathub GitHub. Note that some of these applications use JSON instead of YAML for their manifest files.

Question 2.2 #

(5 of the 25 points)

Now logout and log back in with a Wayland windowing environment (confirm by executing echo $XDG_SESSION_TYPE). Try your keylogger Flatpak again and describe what happens. Discuss the security implications of the X11 Flatpak permission for X11 users vs. Wayland users.

Question 2.3 #

(5 extra credit points)

X11 can also potentially be used to escape the sandbox. Reimplement this X11 attack on Snap but in a Flatpak environment. Note that I’m not asking for the full library injection, just using X11 to inject commands into a terminal and execute them. Provide screenshots and code to receive the extra credit.

Note: I have not tested this myself, but it seems feasible.

Part 3: Sandbox Escape #

(25 points)

At this point, you’ve probably realized that the security of a sandbox is only as good as the policy defined for the sandbox. In this part, we will explore the importance of the sandbox further.

If a Flatpak is given the filesystem=host or filesystem=home permission, it may read and write any files in the users’ home directory. To some extent, this defeats the purpose of sandboxing the application. However, you could argue that the application is still executing within the confines of the sandbox policy. However, a sandbox escape can occur when a policy is not tamperproof (recall Anderson’s three reference monitor properties). Usually, we think of an implementation flaw as violating tamperproofness; however, it can also result from a policy flaw.

Question 3.1 #

(10 of the 25 points + 5 bonus points)

flatkill.org argues that the “[Flatpak] sandbox is a lie” by noting that many applications have either host or home filesystem access, and it is trivial to append malicious commands to the user’s ~/.bashrc. These (unsandboxed) commands will be executed the next time the user opens a terminal or logs in. However, the problem is actually worse. With access to the users’ home directory, a Flatpak can override its policy by writing to ~/.local/share/flatpak/overrides. Flatpak Issue #3637 details this sandbox escape as well as a proof-of-concept Flatpak. A recent update to Flatpak patches this vulnerability by blocking write access to ~/.local/share/flatpak/overrides by default, as mentioned in a rebuttal to flatkill.org.

For this question, you are to build and install a proof of concept exploit that appends malicious commands to the users ~/.bashrc file and confirm it works. In your PDF report, include the following:

• A screenshot of the exploit to demonstrate it works.
• The complete exploit script. Please include this within the PDF report itself.
• Your Flatpak configuration file. Please include this within the PDF report itself.

For five bonus points, build a proof of concept exploit that performs a sandbox escape by modifying the policy of the Flatpak and confirm it works.

Hint: The policy file may have changed location from ~/.local/share/flatpak/overrides.

Question 3.2 #

(15 of the 25 points)

Fortunately, Flatpak applications don’t need filesystem=home to access your files. As indicated in the permissions reference, a Flatpak manifest can specify filesystem=xdg-documents and filesystem=xdg-downloads to access only the user’s ~/Documents and ~/Downloads directories. Restricting file system access in this way will prevent the sandbox escape from Question 3.1. There is even a way to access user files without having any permissions by using the XDG FileChoser portal API, which has GNOME or KDE prompt the user to select a file. Since this file selection occurs outside the Flatpak sandbox, the Flatpak can only access files chosen by the user. Unfortunately, using the document portal requires changes to the application code.

For this question, identify a handful (at least 3; 5 points each) of Flatpak applications that have filesystem=home or filesystem=host. Use FlatSeal to modify their policy to use filesytem=xdg-documents and filesystem=xdg-downloads. Discuss how well this works. Are there any impacts to usability? Also experiment with the --persist=path option described in the sandbox documentation (e.g., to aid with files in ~/.config).

Part 4: Security Model #

(25 points)

When browsing Flathub, you may see application descriptions with statements indicating that the Flatpak is not affiliated with the developer of the application. For example, the Zoom Flatpak states:

NOTE: This wrapper is not verified by, affiliated with, or supported by zoom.us.

This leads to an interesting security observation: the Flatpak package maintainer is not always the application developer.

Note that while users place a lot of trust into package maintainers, the Flathub repository provides transparency. It maintains all application build files in GitHub. For example, the Zoom build files show the URL and SHA256 hash of the application binary used by the Zoom Flatpak. Flathub automatically builds Flatpaks from the files in GitHub.

Question 4.1 #

(15 of the 25 points)

Define a security model for Flatpaks. That is, define the trust model and the threat model. See Lecture 2 for additional detail on security models and concepts.

For the trust model, you should at a minimum define:

• who are the participants? (e.g., app developer, package maintainer, end-user)
• what are the participants trusted to do vs. not do?
• what parts of the system (code, configuration, data, policy) are trusted?
• what are those parts trusted to do vs. not do?

For the threat model, you should at a minimum define:

• who are the adversaries? (they may also be participants)
• what are the goals of the adversary?
• what are the capabilities of the adversary?

When considering the security model, recall that a sandbox is useful in two scenarios: (a) when the sandboxed application is untrusted and may be malicious, and (b) when the sandboxed application is assumed to be benign, but may contain exploitable vulnerabilities.

Question 4.2 #

(10 of the 25 points)

Now that you have completed all of the above, it’s time to reflect on the arguments made by flatkill.org. Do you agree or disagree with the arguments? Take a position and argue for it. In your response, be sure to touch upon:

• Is the old “Sandboxed” badge in GNOME Software is appropriate? Does the new installation GUI address concerns?
• Is a system that uses Flatpaks more / less / equally as secure as a system that does not?