Secure your Linux services with this guide to systemd’s little-known security options

Systemd has some little-known options to help you sandbox and lock down services

Systemd doesn’t just start and stop services… it can do a whole bunch of other stuff too. The problem is, most of us don’t know about it! But fortunately there’s a cheatsheet and command to help you. So if you’re creating a systemd service, consider using this handy guide to add some much-needed security to your services.

Why systemd is a “power tool”

So what exactly is systemd? Systemd is basically a controller, at the heart of your modern Linux system, which starts and manages services in your userspace. (Userspace is the technical term for the area of a Linux-based operating system where you run programs; in other words, userspace is the bit that’s not the Linux kernel.)

Systemd lets you configure your services in infinite ways. You can run services on a schedule, configure an action to take when a service fails, configure a service to automatically start its dependent services, and more. You could probably spend your whole career studying systemd. (And it’d be a fine career choice, to be honest.) But most of us want to get the most out of these tools without studying them for years.

Source: Hacker News

Instantly see how secure your services are

Systemd usually runs as the first process on boot (PID 1), which means that it has an awful lot of power over your Linux environment. “With great power, comes great responsibility,” they say. So for something with that amount of power, it’s helpful to have some checks and balances.

Systemd comes with a command line tool called systemd-analyze security which shows you instantly whether your services are using its security options. It gives each service an “exposure” score. I ran systemd-analyze security on my Linux workstation, and I got these results:

Systemd Analyze Security results

These results are not exactly encouraging for my Linux skills! But I’m running a Linux personal desktop; you might be aiming for different results if you’re running a database server in production. 😉

Try this cheatsheet to create more secure services

So once you’ve analyzed your services, you might want to add some security settings to them. Perhaps you want to sandbox your services, or prevent them from acquiring additional permissions. To do this you need to know the settings you need to add to your unit files.

These settings are all documented in the official documentation but is there an example? Yes! GitHub user Kevin Gallagher (ageis) did the hard work and created this awesome cheatsheet which shows some default systemd unit security settings and includes the relevant sections of the systemd docs, so you can find out more about them. Sharing here because I think it’s great:

Get the cheatsheet on GitHub Gist

Now you’ll be on your way to sandboxing your services, limiting their access to the file system, hiding access to the bits of the system that they don’t need, and so on.

Read more about systemd

If you want to get more help you can always check out the manual pages by typing man. The manual pages are really detailed and accurate.

Personally, I like to peruse the man pages – of a Sunday morning – whilst wearing a monocle and a tweed jacket. 🧐 If you want to do the same, you can read an introduction to systemd with:

man 1 systemd

Or, see all of the options you can use in a unit file with:

man 5 systemd.unit

As always, you can list all of the systemd manual pages using man -k systemd.

Happy service-writing!

Tom Donohue

By Tom Donohue, Editor | Twitter | LinkedIn

Tom is the founder of Tutorial Works. He’s an engineer and open source advocate. He uses the blog as a vehicle for sharing tutorials, writing about technology and talking about himself in the third person. His very first computer was an Acorn Electron.

Join the discussion

Got some thoughts on what you've just read? Want to know what other people think? Or is there anything technically wrong with the article? (We'd love to know so that we can correct it!) Join the conversation and leave a comment.

Comments are moderated.