Running podman within backup hooks is blocked by CapabilityBoundingSet in systemd service file #927

Closed
opened 2024-11-03 16:35:26 +00:00 by cardil · 4 comments

This prevents from running podman-exec within backup hooks. I think it's not a good idea to propose that as a default.

CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_RAW

For pre-packaged deployments like this Fedora' one, the service file is used: https://src.fedoraproject.org/rpms/borgmatic/blob/f40/f/borgmatic.spec#_49

That's tricky to replace those setting with the defaults. Here is my replacement drop-in (in /etc/systemd/system/borgmatic.service.d/reset-capabilites.conf):

[Service]
CapabilityBoundingSet=~
LockPersonality=false
MemoryDenyWriteExecute=no
NoNewPrivileges=no
PrivateDevices=no
PrivateTmp=no
ProtectClock=no
ProtectControlGroups=no
ProtectHostname=no
ProtectKernelLogs=no
ProtectKernelModules=no
ProtectKernelTunables=no
RestrictAddressFamilies=
RestrictNamespaces=no
RestrictRealtime=no
RestrictSUIDSGID=no
SystemCallArchitectures=
SystemCallFilter=
SystemCallErrorNumber=
ProtectSystem=off
This prevents from running podman-exec within backup hooks. I think it's not a good idea to propose that as a default. https://projects.torsion.org/borgmatic-collective/borgmatic/src/commit/13878be2549ca9f1a3d443f59fe2482e545d0192/sample/systemd/borgmatic.service#L52 For pre-packaged deployments like this Fedora' one, the service file is used: https://src.fedoraproject.org/rpms/borgmatic/blob/f40/f/borgmatic.spec#_49 That's tricky to replace those setting with the defaults. Here is my replacement drop-in (in `/etc/systemd/system/borgmatic.service.d/reset-capabilites.conf`): ```systemd [Service] CapabilityBoundingSet=~ LockPersonality=false MemoryDenyWriteExecute=no NoNewPrivileges=no PrivateDevices=no PrivateTmp=no ProtectClock=no ProtectControlGroups=no ProtectHostname=no ProtectKernelLogs=no ProtectKernelModules=no ProtectKernelTunables=no RestrictAddressFamilies= RestrictNamespaces=no RestrictRealtime=no RestrictSUIDSGID=no SystemCallArchitectures= SystemCallFilter= SystemCallErrorNumber= ProtectSystem=off ```
Owner

Thanks for taking the time to file this. Unfortunately, there's no one-size-fits-all systemd configuration for a program as flexible as borgmatic, which is why this is only a "sample" systemd service file. For your use case, I'd recommend starting with a systemd configuration like your replacement drop-in, disregarding the "official" sample service file except as a reference.

Also, side note: Since you're running podman exec.. If you have any thoughts or requirements about borgmatic Podman support, feel free to weigh in on these tickets: #797, #671, and #685.

Thanks for taking the time to file this. Unfortunately, there's no one-size-fits-all systemd configuration for a program as flexible as borgmatic, which is why this is only a "sample" systemd service file. For your use case, I'd recommend starting with a systemd configuration like your replacement drop-in, disregarding the "official" sample service file except as a reference. Also, side note: Since you're running podman exec.. If you have any thoughts or requirements about borgmatic Podman support, feel free to weigh in on these tickets: #797, #671, and #685.
Author

Sure. One size can't fit all, but please notice the Fodora devs took this sample file as a canonical way for setting the service file. And that file is automatically installed on your OS when you do dnf install borgmatic. I bet other OS' devs might do the same.

So, my proposal would be to provide a default service file with loosened security to allow any root tasks in the hooks. Of course, there might be another sample with more secure setup (the current one).

In that way, OS' devs might continue to rely on the sample from upstream sources, and it would not cause friction for the new users. WDYT?

Sure. One size can't fit all, but please notice the Fodora devs [took this sample file](https://src.fedoraproject.org/rpms/borgmatic/blob/f40/f/borgmatic.spec#_49) as a canonical way for setting the service file. And that file is automatically installed on your OS when you do `dnf install borgmatic`. I bet other OS' devs might do the same. So, my proposal would be to provide a default service file with loosened security to allow any root tasks in the hooks. Of course, there might be another sample with more secure setup (the current one). In that way, OS' devs might continue to rely on the sample from upstream sources, and it would not cause friction for the new users. WDYT?
Owner

This is unfortunately one of those age-old trade-offs: Convenience vs. security. There are already two sample systemd service files maintained by the project (root and user service), and I'd rather not be responsible for maintaining yet another—especially one that strips away all (most?) of the security protections. (I'm a believer in "secure by default" as much as possible.) And yet I can appreciate the tough place this puts distribution maintainers in. My recommendation for them is either:

  1. Start from whole cloth with a borgmatic service file tailored to your users' needs that's not based on upstream. But even in that case, I don't recommend disabling all security settings by default. I think a user who is expected to configure borgmatic could be expected to update their borgmatic systemd service file based on their individual needs.
  2. Or: If there are only a few problematic security settings that you want to disable for all users of your distribution, a quick sed (or similar) on the upstream service file within a package build script should take care of that.

Having said that, if there are a few settings that are just too aggressive for most users, I'd be happy to modify the existing sample. But I'm pretty sure that most users don't run podman-exec from a borgmatic hook!

Additionally, if I can make any updates to the borgmatic docs (or service file comments) to better clarify any of this for users, please let me know.

Thanks for your (presumed) understanding!

This is unfortunately one of those age-old trade-offs: Convenience vs. security. There are already two sample systemd service files maintained by the project (root and user service), and I'd rather not be responsible for maintaining yet another—especially one that strips away all (most?) of the security protections. (I'm a believer in "secure by default" as much as possible.) And yet I can appreciate the tough place this puts distribution maintainers in. My recommendation for them is either: 1. Start from whole cloth with a borgmatic service file tailored to your users' needs that's not based on upstream. But even in that case, I don't recommend disabling all security settings by default. I think a user who is expected to configure borgmatic could be expected to update their borgmatic systemd service file based on their individual needs. 2. Or: If there are only a few problematic security settings that you want to disable for all users of your distribution, a quick sed (or similar) on the upstream service file within a package build script should take care of that. Having said that, if there are a few settings that are just too aggressive for most users, I'd be happy to modify the existing sample. But I'm pretty sure that most users don't run `podman-exec` from a borgmatic hook! Additionally, if I can make any updates to the borgmatic docs (or service file comments) to better clarify any of this for users, please let me know. Thanks for your (presumed) understanding!
Owner

Closing due to inactivity, but I'd still be happy to discuss. Thanks!

Closing due to inactivity, but I'd still be happy to discuss. Thanks!
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#927
No description provided.