9 ms·

Mastering systemd: Securing and sandboxing applications and services

190 points by kureikain 7y ago

david_draco 7y ago
This is cool. But how do I use these sandboxing if I want to run a desktop GUI application?
- jchw 7y ago
  I think the effective answer is you don’t; this is for services. However, sandboxes for this specific purpose exists too: Flatpak, for example. If you want to sandbox programs that are part of the system installation, Firejail can provide pretty useful sandboxing. SELinux and AppArmor also can be configured directly, and some distros will come with default configuration for system apps. No one solution will ever be a panacea for either security or use cases, but together they can help build a setup with defense-in-depth.
  - Koshkin 7y ago
    > this is for services "applications and services"
    - jchw 7y ago
      Different definition of applications. I think “services” is closer to what most people are thinking.
- tapoxi 7y ago
  Probably Flatpak (https://flatpak.org/ https://flatpak.org/) which uses bubblewrap to sandbox the application.
- reddotX 7y ago
  you use snapcraft https://snapcraft.io/ https://snapcraft.io/
  - ATsch 7y ago
    Not to start a flamewar, but I'd like to point out why I think snap is not only inferior to flatpak technically but actually a threat to the linux desktop: Snap is very deliberately centralized, with a single hard-coded repo URL. The server is also closed-source. This is because snap's somewhat transparent primary goal is to give Canonical central control of app installation across all linux distributions. The plan from there will include taking cuts of sales revenue and publishing fees. The pieces for this (like DRM) are falling into place. Flatpak, because it isn't born out of such business a model, supports an arbitrary number of user-defined repos, which are trivial to host because they are static folders and can be installed with a single-click via a `flatpakrepo` url. This is on top of other advantages such as upstream support from the likes of GNOME, support for sharing code between apps using "frameworks", supporting themes, using namespaces instead of modified AppArmor, p2p support, a better permission system, etc.
  - inshadows 7y ago
    Snapcraft is about Canonical control over devices, the sandbox is just a mean to an end. Snapcraft leaves you with no control over which code runs on your device.
- pengaru 7y ago
  It takes some fussing about but you can do it in more or less the obvious way. I regularly use firefox in a systemd-nspawn container, the only annoying thing at this time is needing root to start the container but there's already a plan for how to fix that and I believe someone has also posted a PR for supporting starting "machines" (in the systemd-machined sense) as a regular user.
- WhatIsDukkha 7y ago
  For this job you probably want to use Firejail - https://github.com/netblue30/firejail https://github.com/netblue30/firejail It's actually more mature for desktop sandboxing then the other solutions because its been effective for years and has a lot of community work on sandboxing - https://github.com/chiraag-nataraj/firejail-profiles https://github.com/chiraag-nataraj/firejail-profiles If you want to use a prepackaged application vs sandboxing a new app or something in your distribution you should go with - https://flathub.org/home https://flathub.org/home Not every app is well sandboxed with flatpak but this is the goal and they are making very good progress. Also a great way to track a larger project that your distribution doesn't keep up to date as you'd like. just to note -- flatpak/flathub use bubblewrap under the covers which is very promising but I don't see the community profiles like firejail yet.
- eeZah7Ux 7y ago
  Use firejail. It comes with hundreds of ready-made profiles for userspace applications. Avoid snap, flatpack and so on as most of them are not really security-oriented.
- dbmueller 7y ago
  (sorry for the piggyback) Something I'd like to see is a simple way to define “containers” on my desktop that would allow me to run sandboxed versions of my standard apps in bundles. The plan would be something like the following. You have a simple gui that would allow you to create new containers, for which you could define what it has access to (specific folders, internet, sound, etc). You could then add apps to your container, and they would only be able to play with each other in the container with the restrictions given. I think that would work with a simple app essentially based on bubblewrap. For example: * A "torrents" container, where the only apps would be firefox, deluge and vlc, and access to no folder in my home directory, but the container would have its own home directory. * An "admin" container, with only firefox and thunderbird and libreoffice, say, and access to my ~/Downloads and ~/Documents folders. You should be able to run the admin.firefox and torrents.firefox side by side, since they'd have different profiles. By default, each container would have its own "virtual filesystem" with no accesss to anything outside (modulo what's really needed), and only by toggling "links" would it be able to access your actual fs tree. The GUI would be easy enough for computer "illiterate" people to work with it. And the GUI would be smart enough to create desktop files with each new application I add to a container, with customized icons. I don't expect it would be too complicated (essentially bookkeeping on top of bubblewrap). If anyone is interested, I'd happily discuss it more!
  - WhatIsDukkha 7y ago
    Look into firejail, see my sibling comment. It does have a gui similar in spirit to what you are asking for but take a look and see if you can pitch in and help.
m23khan 7y ago
Nice - wondering if these are applicable to centOS as well given that centOS is touted as the freeware version of RHEL.
- akeck 7y ago
  I expect that's the case. For the most part, CentOS has feature parity with RHEL.
  - nightfly 7y ago
    CentOS is RHEL without the RHEL branding.
    - kyuudou 7y ago
      Also, you can update and upgrade without an RHN subscription. Technically, it's a complete recompile of the source code used for RHEL into CentOS rpm packages.
- papercrane 7y ago
  Yes, these mostly look to be features in mainline systemd and should work in any distro using systemd (assuming that version of systemd has these options.)
- fpoling 7y ago
  I use those features in Debian 10. Even Debian 9 supports most of them.
fpoling 7y ago
This sandboxing for services provides similar isolation as various container runtimes. Plus due to integration with systemd things like live update without dropping a single connection is possible to implement with straightforward application code.
- thu2111 7y ago
  If I understand Docker correctly, it's not actually intended to be a sandbox and wasn't designed as such (e.g. the daemon runs as root, or at least used to). It's not clear to me what the threat model for running untrusted Docker images is, or how you'd know what the expected set of permissions were except by reading a README. Whereas this feature is explicitly a sandboxing feature, and the needed permissions are enumerated by the service file.
  - colechristensen 7y ago
    Cgroups limit the impact anything inside the container can do to anything outside the container. It doesn't matter that the daemon runs as root, it starts processes in an a way that prevents them from interacting with other daemons, filesystems, etc. resources. You don't quite understand docker correctly :)
    - TheDong 7y ago
      It's not cgroups, but rather namespaces and seccomp (and apparmor/selinux on some distros) that sandbox the processes inside the container. cgroups are used mostly for resource limits, not for sandboxing (aka namespacing). docker by default does have a slightly more lax security posture than systemd or lxc (i.e. a default set of capabilities that isn't explicitly enumerated and a focus on UX over tweaking them, no usernamespaces by default, etc), though you're right that it is largely meant to be a secure sandbox for untrusted containers, as long as you know hat you're doing.
      - colechristensen 7y ago
        Ah, I was under the impression that namespacing was a part of cgroups in general.
thu2111 7y ago
I have to admit, having recently spent some time learning it and updating my Linux skills I really don't understand why systemd seems to have provoked so much hate and controversy in the Linux world. So far I really like it. It makes a Linux server feel more like something designed rather than incrementally patched together out of hacky shell scripts written 20 years ago. The unit config files are small and simple. Every line makes sense. Things are coherent - learning how to start a service at bootup means you've partly learned how to configure the new equivalent of cron jobs. The same configuration works at the system and per-user level. You can quickly locate logs. I didn't quite like the command line interface at first e.g. why "systemctl" and not "service", plus I always forget if it's the service name in the second or first position. But the basic functionality is all there. I realise Docker is all the rage at the moment but I've found it kind of flaky and complicated. For my own purposes systemd feels about the right level of abstraction. It's not picky about where software comes from, it just manages it. You can unzip a tarball and make it run isolated, depend on other services, and a whole lot of other neat things. If you've learned it on one distro you learned it for the rest, unlike SysV init. And it seems to constantly get more useful features that are all pretty easy to configure as well.
- 2OEH8eoCRo0 7y ago
  >I really don't understand why systemd seems to have provoked so much hate and controversy in the Linux world. Because the OSS community is dense with insecure and pedantic neckbeards. Lennart Poettering, Systemd's creator, has received death threats over it ffs. I too find it quite elegant and easy to use.
  - benhameen 7y ago
    https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo
    - exo762 7y ago
      Oh, the talk that made me learn systemd. Must see.
LockAndLol 7y ago
What I'd like to know is how whether it's possible run GUI applications in their own containers. From what I understand about X, if a GUI app runs in the same context as the DE, it will have access to all other windows, the clipboard, etc. That makes me think that Xephyr is mandatory in order to run an app in a container, but I haven't found a satisfactorily easy way to do so. Would systemd be the easy solution I'm looking for?
- mook 7y ago
  Firejail, mentioned elsewhere in the thread, should do that correctly. Personally though I've been doing docker (substitute with systemd-nspawn or whatever you like) with xpra; not sure it's as secure, but it should block accidental snooping while still supporting clipboard transfers. It appears that the relevant developers are pushing towards using Wayland for more secure remote windowing, but I do not know what state it's in.
proactivesvcs 7y ago
The official documentation on these directives was of great value when I started looking into unit file hardening. There were a few minor cases where I had to, or felt the need to go elsewhere for deeper explanation, but for the most part it was readable and comprehensive. I was able to understand the changes that I made and while carefully testing, few unexpected problems resulted. The changes that I applied as a result of this has meant the unit files now score around 1.5 from the "systemctl-analyze security" system. Considering I approached the process with almost no knowledge of systemd, this speaks volumes on the quality of the documentation, its timeliness and practical relevance, and the fruit that can be borne of excellent documentation.
- lovelettr 7y ago
  Was that the freedesktop.org wiki?
  - proactivesvcs 7y ago
    Primarly the systemd.exec man page at https://www.freedesktop.org/software/systemd/man/systemd.exec.html https://www.freedesktop.org/software/systemd/man/systemd.exe... , as well as the accompanying unit and service file man pages for more general reference.

190 points by kureikain 7y ago

david_draco 7y ago

This is cool. But how do I use these sandboxing if I want to run a desktop GUI application?

jchw 7y ago
I think the effective answer is you don’t; this is for services. However, sandboxes for this specific purpose exists too: Flatpak, for example. If you want to sandbox programs that are part of the system installation, Firejail can provide pretty useful sandboxing. SELinux and AppArmor also can be configured directly, and some distros will come with default configuration for system apps. No one solution will ever be a panacea for either security or use cases, but together they can help build a setup with defense-in-depth.
- Koshkin 7y ago
  > this is for services "applications and services"
  - jchw 7y ago
    Different definition of applications. I think “services” is closer to what most people are thinking.
tapoxi 7y ago
Probably Flatpak (https://flatpak.org/ https://flatpak.org/) which uses bubblewrap to sandbox the application.
reddotX 7y ago
you use snapcraft https://snapcraft.io/ https://snapcraft.io/
- ATsch 7y ago
  Not to start a flamewar, but I'd like to point out why I think snap is not only inferior to flatpak technically but actually a threat to the linux desktop: Snap is very deliberately centralized, with a single hard-coded repo URL. The server is also closed-source. This is because snap's somewhat transparent primary goal is to give Canonical central control of app installation across all linux distributions. The plan from there will include taking cuts of sales revenue and publishing fees. The pieces for this (like DRM) are falling into place. Flatpak, because it isn't born out of such business a model, supports an arbitrary number of user-defined repos, which are trivial to host because they are static folders and can be installed with a single-click via a `flatpakrepo` url. This is on top of other advantages such as upstream support from the likes of GNOME, support for sharing code between apps using "frameworks", supporting themes, using namespaces instead of modified AppArmor, p2p support, a better permission system, etc.
- inshadows 7y ago
  Snapcraft is about Canonical control over devices, the sandbox is just a mean to an end. Snapcraft leaves you with no control over which code runs on your device.
pengaru 7y ago
It takes some fussing about but you can do it in more or less the obvious way. I regularly use firefox in a systemd-nspawn container, the only annoying thing at this time is needing root to start the container but there's already a plan for how to fix that and I believe someone has also posted a PR for supporting starting "machines" (in the systemd-machined sense) as a regular user.
WhatIsDukkha 7y ago
For this job you probably want to use Firejail - https://github.com/netblue30/firejail https://github.com/netblue30/firejail It's actually more mature for desktop sandboxing then the other solutions because its been effective for years and has a lot of community work on sandboxing - https://github.com/chiraag-nataraj/firejail-profiles https://github.com/chiraag-nataraj/firejail-profiles If you want to use a prepackaged application vs sandboxing a new app or something in your distribution you should go with - https://flathub.org/home https://flathub.org/home Not every app is well sandboxed with flatpak but this is the goal and they are making very good progress. Also a great way to track a larger project that your distribution doesn't keep up to date as you'd like. just to note -- flatpak/flathub use bubblewrap under the covers which is very promising but I don't see the community profiles like firejail yet.
eeZah7Ux 7y ago
Use firejail. It comes with hundreds of ready-made profiles for userspace applications. Avoid snap, flatpack and so on as most of them are not really security-oriented.
dbmueller 7y ago
(sorry for the piggyback) Something I'd like to see is a simple way to define “containers” on my desktop that would allow me to run sandboxed versions of my standard apps in bundles. The plan would be something like the following. You have a simple gui that would allow you to create new containers, for which you could define what it has access to (specific folders, internet, sound, etc). You could then add apps to your container, and they would only be able to play with each other in the container with the restrictions given. I think that would work with a simple app essentially based on bubblewrap. For example: * A "torrents" container, where the only apps would be firefox, deluge and vlc, and access to no folder in my home directory, but the container would have its own home directory. * An "admin" container, with only firefox and thunderbird and libreoffice, say, and access to my ~/Downloads and ~/Documents folders. You should be able to run the admin.firefox and torrents.firefox side by side, since they'd have different profiles. By default, each container would have its own "virtual filesystem" with no accesss to anything outside (modulo what's really needed), and only by toggling "links" would it be able to access your actual fs tree. The GUI would be easy enough for computer "illiterate" people to work with it. And the GUI would be smart enough to create desktop files with each new application I add to a container, with customized icons. I don't expect it would be too complicated (essentially bookkeeping on top of bubblewrap). If anyone is interested, I'd happily discuss it more!
- WhatIsDukkha 7y ago
  Look into firejail, see my sibling comment. It does have a gui similar in spirit to what you are asking for but take a look and see if you can pitch in and help.

m23khan 7y ago

Nice - wondering if these are applicable to centOS as well given that centOS is touted as the freeware version of RHEL.

akeck 7y ago
I expect that's the case. For the most part, CentOS has feature parity with RHEL.
- nightfly 7y ago
  CentOS is RHEL without the RHEL branding.
  - kyuudou 7y ago
    Also, you can update and upgrade without an RHN subscription. Technically, it's a complete recompile of the source code used for RHEL into CentOS rpm packages.
papercrane 7y ago
Yes, these mostly look to be features in mainline systemd and should work in any distro using systemd (assuming that version of systemd has these options.)
fpoling 7y ago
I use those features in Debian 10. Even Debian 9 supports most of them.

fpoling 7y ago

This sandboxing for services provides similar isolation as various container runtimes. Plus due to integration with systemd things like live update without dropping a single connection is possible to implement with straightforward application code.

thu2111 7y ago
If I understand Docker correctly, it's not actually intended to be a sandbox and wasn't designed as such (e.g. the daemon runs as root, or at least used to). It's not clear to me what the threat model for running untrusted Docker images is, or how you'd know what the expected set of permissions were except by reading a README. Whereas this feature is explicitly a sandboxing feature, and the needed permissions are enumerated by the service file.
- colechristensen 7y ago
  Cgroups limit the impact anything inside the container can do to anything outside the container. It doesn't matter that the daemon runs as root, it starts processes in an a way that prevents them from interacting with other daemons, filesystems, etc. resources. You don't quite understand docker correctly :)
  - TheDong 7y ago
    It's not cgroups, but rather namespaces and seccomp (and apparmor/selinux on some distros) that sandbox the processes inside the container. cgroups are used mostly for resource limits, not for sandboxing (aka namespacing). docker by default does have a slightly more lax security posture than systemd or lxc (i.e. a default set of capabilities that isn't explicitly enumerated and a focus on UX over tweaking them, no usernamespaces by default, etc), though you're right that it is largely meant to be a secure sandbox for untrusted containers, as long as you know hat you're doing.
    - colechristensen 7y ago
      Ah, I was under the impression that namespacing was a part of cgroups in general.

thu2111 7y ago

I have to admit, having recently spent some time learning it and updating my Linux skills I really don't understand why systemd seems to have provoked so much hate and controversy in the Linux world. So far I really like it. It makes a Linux server feel more like something designed rather than incrementally patched together out of hacky shell scripts written 20 years ago. The unit config files are small and simple. Every line makes sense. Things are coherent - learning how to start a service at bootup means you've partly learned how to configure the new equivalent of cron jobs. The same configuration works at the system and per-user level. You can quickly locate logs. I didn't quite like the command line interface at first e.g. why "systemctl" and not "service", plus I always forget if it's the service name in the second or first position. But the basic functionality is all there. I realise Docker is all the rage at the moment but I've found it kind of flaky and complicated. For my own purposes systemd feels about the right level of abstraction. It's not picky about where software comes from, it just manages it. You can unzip a tarball and make it run isolated, depend on other services, and a whole lot of other neat things. If you've learned it on one distro you learned it for the rest, unlike SysV init. And it seems to constantly get more useful features that are all pretty easy to configure as well.

2OEH8eoCRo0 7y ago
>I really don't understand why systemd seems to have provoked so much hate and controversy in the Linux world. Because the OSS community is dense with insecure and pedantic neckbeards. Lennart Poettering, Systemd's creator, has received death threats over it ffs. I too find it quite elegant and easy to use.
- benhameen 7y ago
  https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo
  - exo762 7y ago
    Oh, the talk that made me learn systemd. Must see.

LockAndLol 7y ago

What I'd like to know is how whether it's possible run GUI applications in their own containers. From what I understand about X, if a GUI app runs in the same context as the DE, it will have access to all other windows, the clipboard, etc. That makes me think that Xephyr is mandatory in order to run an app in a container, but I haven't found a satisfactorily easy way to do so. Would systemd be the easy solution I'm looking for?

mook 7y ago
Firejail, mentioned elsewhere in the thread, should do that correctly. Personally though I've been doing docker (substitute with systemd-nspawn or whatever you like) with xpra; not sure it's as secure, but it should block accidental snooping while still supporting clipboard transfers. It appears that the relevant developers are pushing towards using Wayland for more secure remote windowing, but I do not know what state it's in.

proactivesvcs 7y ago

The official documentation on these directives was of great value when I started looking into unit file hardening. There were a few minor cases where I had to, or felt the need to go elsewhere for deeper explanation, but for the most part it was readable and comprehensive. I was able to understand the changes that I made and while carefully testing, few unexpected problems resulted. The changes that I applied as a result of this has meant the unit files now score around 1.5 from the "systemctl-analyze security" system. Considering I approached the process with almost no knowledge of systemd, this speaks volumes on the quality of the documentation, its timeliness and practical relevance, and the fruit that can be borne of excellent documentation.

lovelettr 7y ago
Was that the freedesktop.org wiki?
- proactivesvcs 7y ago
  Primarly the systemd.exec man page at https://www.freedesktop.org/software/systemd/man/systemd.exec.html https://www.freedesktop.org/software/systemd/man/systemd.exe... , as well as the accompanying unit and service file man pages for more general reference.