Blog on Petr Mánek – personal homepage

Why I keep a gigabyte-sized file on my file system

Sat, 14 Jan 2023 00:00:00 +0000

More and more often these days I find myself approaching the limit of available space on my laptop’s solid-state drive. With only a gigabyte left and a lot of development activity ongoing, it is not uncommon for my system to run out of space every now and then.

On Linux systems having no storage left is far from fatal. The kernel resides in memory, swapping relies on a dedicated partition, and any self-respecting I/O activities can be expected to fail gracefully. That being said, there are indirect effects that are annoying as hell. For instance, my shell maintains a history file containing recent commands. If this file cannot be modified for some reason, an error message is printed every single time I execute a command; even worse, in some cases new shells cannot even be opened. For that reason alone, having no free space for extended periods of time can be viewed as potentially dangerous, as it can effectively lock me out of my shell.

At some point in the future, my current situation will inevitably trigger a spring cleanup, a storage upgrade, or ideally both. Until such time, however, I found¹ a low-effort mitigation method: on my root file system I created a dummy file filled with one gigabyte of zeros. Most of the time this file just sits there, but whenever I run out of space I can alleviate the problem by removing it. This immediately restores some stability to my system, and usually buys me enough time to diagnose the issue and find a longer-term solution. I am aware that this approach is rather primitive. However, thus far it has proven surprisingly effective in making my work life bearable even though I am living on the edge.

If you would like to try it, here are some instructions. Inside my root shell, I create the dummy file at /opt/gigabyte using the following command:²

# dd if=/dev/zero of=/opt/gigabyte bs=1M count=1024

I remember having read about this technique somewhere online in the past. Unfortunately, at the time of writing this I was unable to track it down. If I ever re-discover it, I will update this post with a link. ↩︎
Disclaimer: dd can wreck your system if used without caution. Please stay safe by thinking twice and dd’ing once! ↩︎

Unlocking gpg-agent using pam_gnupg

Thu, 29 Dec 2022 00:00:00 +0000

Background: how I manage my passwords

To manage sensitive data I use pass, a password manager that encrypts secrets using asymmetric cryptography implemented by GnuPG. By design this means that whenever I want to use a secret, I am prompted to reveal the passphrase of my private key, so that the secret can be decrypted on the spot. As secure as this practice may be, one easily grows tired of entering one’s passphrase every. single. time. in order to do anything meaningful. In my humble opinion, basic security should not be cumbersome.

GnuPG offers an easy remedy: you can leave gpg-agent running in the background of your session, and it will securely remember all your previously entered passphrases. As long as your passphrase is cached, you will not be bothered to enter it again¹. This is convenient for sure but it comes with a security trade-off: a malicious actor could potentially exploit your laziness by decrypting all your cached passphrases from a memory dump². Fortunately, GnuPG permits to mitigate this risk to some extent by tuning the cache duration in your ~/.gnupg/gpg-agent.conf³. This forces gpg-agent to eventually forget all passphrases that are not used too frequently, thereby limiting the secrets any attackers may be able to exfiltrate.

For instance, the following configuration will have gpg-agent cache your passphrases for an hour.

default-cache-ttl   3600
max-cache-ttl       3600

Side note: If you just pasted the above lines in your gpg-agent.conf, your gpg-agent is currently running and you expect to see changes immediately, hold your horses! You will need to restart it, or at least force it to reload its settings by running the following command. Coincidentally this command will also clear your gpg-agent’s cache, which will be useful later.

$ gpg-connect-agent --no-autostart reloadagent /bye

Automatic unlocking with pam_gnupg

I have been happily using GnuPG like this for a long time. Recently, however, I discovered a neat improvement: if your GnuPG passphrase can be derived⁴ from your login password, you can configure PAM to automatically pass it on to gpg-agent upon login. The agent will cache the passphrase, and not bother you to enter it for the first time after rebooting; not even once. This feature is called presetting and can save you some time. Let me demonstrate how it can be set up.

First of all, presetting has to be explicitly enabled in your gpg-agent.conf by adding the following line:

allow-preset-passphrase

Once enabled, passphrases can be preset from many sources. To this end GnuPG ships a simple program called gpg-preset-passphrase that I found convenient for testing. You may have to look for it on your file system as it usually lives in the libexec directory rather than the conventional bin directory. My distribution places it in /usr/lib/gnupg/.

When you manage to locate the program, its invocation is simple enough:

$ /usr/lib/gnupg/gpg-preset-passphrase --preset $KEYGRIP <passfile

Here $KEYGRIP is the hexadecimal string that uniquely identifies the GnuPG key that you wish to unlock, and for testing I temporarily placed⁵ my passphrase in a file called passfile⁶.

When you confirm that your gpg-agent can receive and successfully cache passphrases, it is time to cut out the middle man. There is a pluggable authentication module (PAM) called pam_gnupg that can harvest your password at the time of login, and pass it on to gpg-agent just like gpg-preset-passphrase. The way PAM works is outside of the scope of this article (if it is new to you have a look in the manual, here or here), however suffice to say that it is an extendable system that facilitates user authentication in Linux. There are many plug-ins that can perform various tasks and behaviors in PAM, and one of them is pam_gnupg. As it is an open-source project, it is possible to install it without much effort.

First you will need to create the ~/.pam-gnupg fill that should contain the value of $KEYGRIP (if you want to unlock more than one key, you will need to put their identifiers on separate lines). After that, you will need to spend a little bit of time as root tinkering in your /etc/pam.d/ directory.

Caution! Modifying PAM chains is an excellent way to lock yourself out of your own computer. As a rule of thumb, when doing these changes I always like to test individual modifications immediately after making them. And just in case, I keep a secondary root shell in the background should I need to roll something back. If you want to err on the side of caution, you should consider backing up your system before you proceed any further. You have been warned!

According to pam_gnupg’s README you need to add the following two lines in your /etc/pam.d/system-local-login file. One at the end of the auth section, the other at the end of the session section.

auth     optional  pam_gnupg.so store-only
session  optional  pam_gnupg.so

These will act as hooks that grab your password when you login to the system. In my case, since I also happen to use swaylock, I inserted the following line at the end of the auth section in my /etc/pam.d/swaylock file:

auth     optional  pam_gnupg.so

The idea behind this is that the same hook can also run when the session is unlocked, e.g. after I stroll away for a long time or after powering up my laptop from sleep. When this happens it is quite likely that gpg-agent will have already forgotten my passphrases, so I may just as well preset them again to save myself some typing.

At this point, it may be wise to verify that your PAM configuration (still) works. The most convenient place to do this for me was with swaylock. I would clear my passphrase cache, lock my session, unlock it and check if there were any passphrases cached. A couple of attempts and one mistyped key identifier later, everything was working as expected (if your mileage differs it is useful to know that pam_gnupg offers a debug option that makes it appear in syslog). Encouraged by this I decided to take a leap of faith and log out completely. After logging back in I was pleased to see that everything worked reliably out of the box. If you run into problems, be sure to check pam_gnupg’s README – it has some suggestions on race conditions etc.

Finally, as a little cherry on top I configured my system to explicitly clear gpg-agent’s cache every time my lockscreen is about to be executed. This should make my laptop less susceptible to memory dumping attacks whenever it is about to go to sleep or I am away from keyboard. This behavior can be implemented using the above-listed gpg-connect-agent command that reloads gpg-agent. In my case I simply wrapped a call to swaylock in a shell script that runs this command first, and substituted it in all references to swaylock in my configuration files.

Final thoughts

And there you have it! With this setup your gpg-agent should be automatically preset with your favorite passphrase when you login, it should forget it whenever you lock your session, and re-discover it after unlocking. Depending on your system, password manager and threat model it may or may not be not be a good solution for you.

This method without doubt introduces some vulnerabilities in the system. Specifically all of this hinges on the ability to derive one passphrase from another, which I would generally never recommend to anyone. For the strongest security, passphrases should be chosen as independently randomly as possible. That being said, rather than achieving the strongest security I was aiming to strike a reasonable balance between acceptable security and day-to-day usability, which is why I believe that in my case this makes sense.

In any case, if nothing else I hope that this helped you learn a bit about GnuPG, PAM and friends.

You may recognize this behavior from other password managers, e.g. macOS Keychain or gnome-keyring, which can both be “unlocked” by the user. I may occasionally allude to this terminology from now on. ↩︎
It is also worth contemplating whether this could be done after the cached passphrases were evicted from memory. ↩︎
Or more generally, $GNUPGHOME/gpg-agent.conf. See: gpg-agent(1) ↩︎
The referenced implementation of pam_gnupg only supports passing the login password to gpg-agent as-is, which requires both strings to be identical. I am generally opposed to sharing keys and passwords for different purposes, so here is my take: since pam_gnupg is open-source, nobody can stop you from forking it and implementing your own transformation function! ↩︎
Note that this is just for testing! I do not store my secrets unencrypted as that defeats the entire purpose of having a password manager in the first place. And even though this is a test, I would certainly recommend setting the mode of passfile to 0600 before placing anything sensitive inside. ↩︎
gpg-preset-passphrase can also read in your passphrase using the --passphrase option. However, I would advise against that as it risks revealing it to all users of your system (generally, anyone with access to your procfs can access the arguments of the process). ↩︎

Fun with sassy sudo

Mon, 25 Apr 2022 00:00:00 +0000

Sudo is often used in system administration but is otherwise a pretty boring tool. If you mistype your password, you get to see the following message:

[sudo] password for user:
Sorry, try again.

Only recently I discovered that there exists an easter egg that permits sudo to randomly insult users upon failed password attempts. This is by default disabled. However, if you explicitly enable it and mess up your password, sudo may print:

[sudo] password for user:
Wrong!  You cheating scum!

…or:

[sudo] password for user:
stty: unknown mode: doofus

…or:

[sudo] password for user:
You type like i drive.

How to enable this

If you would like to give your sudo a bit of sass, you can enable this easter egg by editing /etc/sudoers (using visudo as root) and adding the following line:

Defaults insults

As always with anything related to sudo, take extra care when modifying the contents of the file otherwise you may end up locking yourself out of root access.

If you are curious like me and do not want to wait until a failed password attempt, you can find all insulting messages embedded inside the /usr/lib/sudo/sudoers.so binary. They can be displayed along with all other strings using the strings tool:

$ strings /usr/lib/sudo/sudoers.so | less

Hope this little tip makes your sudoing a bit more fun!

Sandboxing Zoom using AppArmor and Firejail

Sat, 23 Apr 2022 00:00:00 +0000

It is no secret that the Zoom video conferencing system has dubious reputation for lying to its users, mistreating their data and censoring their speech. In spite of all that, it has become a standard communication tool that I am expected to use at work several times a week. Since avoiding it unfortunately is not an option that would be available to me, I decided to at least mitigate any potential damage from Zoom by running it inside a sandbox. I was inspired to do this after reading this article.

While there exist various technical implementations, all sandboxes generally achieve the same result – they let the user control individual capabilities of programs that are confined inside. Since Zoom relies on active Internet connection, I had no illusions that I would be able to increase the protection of my calls or deny the app from sending telemetry. Instead I decided to focus mostly on restricting its capability to snoop around my file system and collect information about me without my permission. The rest of this post documents the steps I took to achieve that.

Step 1: Install AppArmor

For this effort, I am using AppArmor – a Linux Security Module that runs directly in the kernel and acts as a middle man between user-space programs and the rest of the system. This gives it the capability to restrict anything interesting that programs might want to do (for instance read files or communicate with the rest of the World) while introducing as little overhead as possible.

After installing the AppArmor kernel module using your favorite package manager, bear in mind that you also need to ensure that it gets loaded on boot. In Archlinux this is done by enabling the apparmor.service in systemd and adding the following kernel parameters:

lsm=landlock,lockdown,yama,apparmor,bpf

Following a reboot, AppArmor should be loaded and ready for use. This can be verified by running:

$ aa-enabled
Yes

Step 2: Install Firejail

AppArmor on its own is just a kernel module, not a sandbox. To supplement it I am using Firejail – a namespace-driven sandboxing program that can exploit AppArmor to efficiently enforce user-defined policies. These policies can be viewed as lists of rules that explicitly define what the confined program is allowed to do.

After Firejail is installed using your favorite package manager, you will need to put together a profile that works for Zoom. This is the balancing act that entails the most trial and error. Fortunately, Firejail profile syntax is really easy to learn, and there exist many examples for inspiration. Based on what I found on GitHub, I put together the following profile that I saved in ~/.config/firejail/zoom.local, ensuring that it is automatically applied whenever the zoom binary is executed:

protocol unix,inet,inet6,netlink
ignore seccomp
seccomp !chroot

This is what the profile above translates to:

Zoom is permitted to use network sockets of the UNIX, IPv4, IPV6 and Netlink families.
Override any previous setting enabling seccomp syscall filters.
Explicitly enable seccomp filter and configure it to disallow the chroot syscall.

Note that this configuration is overlaid on any other default profiles that come with your installation of Firejail. In my environment, Firejail applies 13 other profiles that blacklist user directories and whitelist common library paths etc.

Step 3: Create a wrapper script

The next step is to create a shell script that runs Zoom within the Firejail sandbox. This script can then be used instead of the Zoom client’s original binary.

My script looks like this:

#!/bin/bash
# A wrapper that confines zoom in a sandbox, faking home directory in ~/.zoom

QT_QPA_PLATFORM=xcb # NOTE: needed otherwise zoom crashes on Wayland :/

function cleanup()
{
	# Auto-mute after zoom terminates
	pactl set-source-mute 1 1
}

trap cleanup EXIT
firejail --apparmor --private=${HOME}/.zoom zoom ${@}

Let me explain the code above bit by bit:

QT_QPA_PLATFORM=xcb is a compatibility hack that is needed because I use a Wayland compositor. It forces Zoom to fallback to a X11 frontend with Xwayland instead of using its native Wayland frontend. While the latter option would of course be preferable, it unfortunately seems to be unstable at this time.
The cleanup function always runs after Zoom exits, and makes sure that my microphone stays muted when I am not in a meeting. I have noticed that Zoom has the nasty habit of unmuting the microphone whenever I unmute myself in meetings, and not bothering to restore the original state afterwards. I would often forget to do this manually, so I created a function that does this on my behalf using PulseAudio¹.
The firejail call is where the most time is spent, as it blocks throughout the entire lifetime of the Zoom client. As you suspect, the --apparmor flag instructs Firejail to enforce the policy using the AppArmor kernel module². The --private flag hides my home directory from Zoom and replaces it with a blank directory that I created in ~/.zoom. The ${@} variable forwards all shell options to the zoom executable; more about that later.

You may be interested to know that over my multi-year usage of Zoom, it has created the following file tree inside my decoy home directory:

.zoom
├── data
│   ├── com.zoom.ipc.assistantapp__req
│   ├── com.zoom.ipc.assistantapp__res
│   ├── com.zoom.ipc.confapp__req
│   ├── com.zoom.ipc.confapp__res
│   ├── zoomus.enc.db
│   ├── zoomus.enc.db.malformed
│   └── zoomus.tmp.enc.db
├── Downloads
├── im
├── logs
│   └── zoom_stdout_stderr.log
├── reports
└── screenCapture

Step 4: Replace Zoom with the wrapper

The final step involves replacing all links to the original Zoom client with links to the wrapper script. In my case, this meant creating a secondary XDG desktop entry that mimics the contents of /usr/share/applications/Zoom.desktop that is by default installed along with Zoom.

I saved my variant to ~/.local/share/applications/JailedZoom.desktop, so that it is discovered automatically by launchers etc. The contents of the file are as follows.

[Desktop Entry]
Name=Zoom (jailed)
Comment=Zoom Video Conference (confined to firejail)
Exec=/home/petr/bin/pm_jailed_zoom %U
Icon=Zoom
Terminal=false
Type=Application
Encoding=UTF-8
Categories=Network;Application;
StartupWMClass=zoom
MimeType=x-scheme-handler/zoommtg;x-scheme-handler/zoomus;x-scheme-handler/tel;x-scheme-handler/callto;x-scheme-handler/zoomphonecall;application/x-zoom
X-KDE-Protocols=zoommtg;zoomus;tel;callto;zoomphonecall;
Name[en_US]=Zoom

Note that my wrapper script is located at ~/bin/pm_jailed_zoom, you may want to customize the Exec path on your system. Also notice that the %U wildcard makes it possible for meeting URLs to be passed to the wrapper, which then forwards it to Zoom inside Firejail through the ${@} variable. This means that one-click meeting URLs should still work with this setup.

After adding the custom desktop entry it is necessary to rebuild the desktop database using the following command:

$ update-desktop-database ~/.local/share/applications

You can then set JailedZoom.desktop to be the default handler for Zoom URLs:

$ xdg-mime default JailedZoom.desktop x-scheme-handler/zoommtg

…and verify by re-querying:

$ xdg-mime query default x-scheme-handler/zoommtg
JailedZoom.desktop

Conclusion

If you reached this point and did everything right, you now have the capability to confine Zoom in a sandbox that keeps it away from your data. In my opinion, this is the least worst way of running Zoom on your system if you have to like me.

Just a couple of obligatory security disclaimers:

Even with this setup Zoom is still present on your system, and can be executed outside of the sandbox if you (or a malicious actor) run it directly without the wrapper script.
While these measures increase protection of your file system, they do not affect your communications conducted over Zoom. You should still treat Zoom as an untrustworthy channel.
I am not a security engineer. This setup may be sufficient for my purposes, but you may want to consider consulting an expert.

In spite of all this effort I would still recommend not using Zoom at all. To anyone who listens, you can get the same set of features without any of the downsides with Jitsi for free.

The "1 1" audio source corresponds to my laptop’s built-in microphone. If you would like to use the auto-muting feature, you may need to choose a different identifier. Run pactl list sources to retrieve a complete list of sinks available in your system. ↩︎
Firejail can sandbox programs even without AppArmor. This, however, comes at the expense of narrower rule support and slightly increased user-space overhead. ↩︎