Replies: 5 comments 41 replies
-
|
Thanks for opening this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Of course sandboxing a service doesn't mean the whole server security is guaranteed, even only regarding the service itself. That neither developer nor admins can rely on this protecting against everything, is, or should be, clear to everyone, but is no argument to just not do sandboxing. It is an additional layer of security around the particular service, which should generally be considered, if there are no downsides. Mainly it may protect against, in whichever way, injected harmful executables, 3rd party libraries and, of course, security and privacy holes in the software itself. Compared to a static service user, a dynamic user has the benefit that it's impossible to grant it any additional permissions to access non-world accessible files, via group or chown. And the dirs it requires access to (state and cache dirs), are chowned automatically by systemd.
Right, but the package postinst script does already not create the user and group anymore, but now actively removes them, if systemd is used. For 3rd party/other distro packages, it would need to be done accordingly, of course, but then one can also add an own systemd service or alter it, if really required.
As said, both dirs are setup by systemd automatically on service start, so that the dynamic user has access. Outside of the service scope, only root has access: ls -al /var/{lib,cache}/private
That is true, those can be removed.
The latest relevant settings are StateDirectory/CacheDirectory, added with systemd v235, released 2017-10-06, part of Ubuntu Bionic and Debian Buster, which I personally would consider sufficient legacy OS support. Does latest myMPD, respectively the builds from the official repositories, work at all on older versions, e.g. RHEL7 🤔?
Sounds like something to investigate separately. If the service starts, then it is likely a setup issue. Or which particular features, which do not work correctly, do you mean? I could imagine that some distros setup MPD a way that the socket is not world-writable, probably this is true on RHEL8? This, like generally access to non-world-accessible files/dirs can be achieved with the |
Beta Was this translation helpful? Give feedback.
-
Only the debian postinst script removes the user/group. This is not implemented for rpms.
Is it the scripting feature with a script that calls commands with sudo? This is rectricted by the hardend systemd unit: https://github.com/jcorporation/myMPD/discussions/916
This peace of software is far too old, to be explicitly supported by myMPD.
The unit file defines |
Beta Was this translation helpful? Give feedback.
-
|
myMPD tries only to drop privileges to the mympd user if it is started as root. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, then it should be fine. I can actually do some testing the next minutes. |
Beta Was this translation helpful? Give feedback.
-
|
Great. The devel branch includes some fixes for the postinst script: #917 |
Beta Was this translation helpful? Give feedback.
-
|
Btw, to check whether a service is actually running: ! systemctl -q is-active mympd || systemctl stop mympdTested with the four settings removed, and watching to music here 🙂: root@VM-Bullseye:~# systemctl cat mympd
# /lib/systemd/system/mympd.service
#
# SPDX-License-Identifier: GPL-3.0-or-later
# myMPD (c) 2018-2022 Juergen Mang <[email protected]>
# https://github.com/jcorporation/mympd
#
[Unit]
Description=myMPD server daemon
Documentation=man:mympd(1)
Requires=network.target local-fs.target
After=mpd.service
[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
DynamicUser=yes
ExecStart=/usr/bin/mympd
LockPersonality=yes
MemoryDenyWriteExecute=yes
PrivateDevices=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
RestrictRealtime=yes
StateDirectory=mympd
CacheDirectory=mympd
RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK AF_UNIX
RestrictNamespaces=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
[Install]
WantedBy=multi-user.target |
Beta Was this translation helpful? Give feedback.
-
|
great and thanks for the hint! |
Beta Was this translation helpful? Give feedback.
-
|
Well ok, this is absolutely not what I meant to say. What I meant to say it should not be default because it does not work out of the box the way it is now on every system where mpd and myMPD otherwise work without problems. (And yes, although I use something more recent, it does work perfectly on EL7 which is supported until June 30, 2024, BTW). RedHat uses the sandboxing features of systemd very sparsely and likely for good reason, it has selinux enabled per default with well thought out (and tested!) policies. These sandboxing features are a solution in search of a problem here, this is not an Android phone. Additionally I certainly do not want to engage in a discussion about how to implement system security as this usually leads to nothing fruitful, it´s to a degree distribution specific and I´m aware that those exited by the latest and greatest features of systemd usually do not listen to those that have been doing this for a living almost three decades. So my points are:
As long as such changes do not interfere with the usability on other systems I don´t care, but I´m concerned it is steering in this way. |
Beta Was this translation helpful? Give feedback.
-
|
So you want to have additional hardening removed from myMPD's systemd service, only because RH, which you do not use, doesn't use them (often)? 🤔
None are done so far, aside of that |
Beta Was this translation helpful? Give feedback.
-
|
myMPD shoud be compatible with any sort of init system. I run myMPD with my Alpine Linux based myMPDos image. Alpine Linux uses openrc. |
Beta Was this translation helpful? Give feedback.
-
|
"because RH, which you do not use" just the opposite, I use RedHat (since 1995 and since 2000 professionally). "None are done so far" yes, and thats good. A selinux policy (like mpd has) probably would be useful, but that´s for another day. |
Beta Was this translation helpful? Give feedback.
-
Looks interesting, I will have a look at Alpine tomorrow (the x86_64 version a rasperry I do not have). |
Beta Was this translation helpful? Give feedback.
-
|
I like alpine because it is really small and can run on a raspberry completely in the ram. |
Beta Was this translation helpful? Give feedback.
-
This should be the case. The service unit changes are pushes from an Arch Linux packager ;) I think only the migration to DynamicUser for distributions with systemd was not good enough tested. |
Beta Was this translation helpful? Give feedback.
-
In fact my older version of Ubuntu doesn't have a new enough version of mpd or cmake for myMPD. I need to compile these from source for myMPD to build/fully function. Adding a hint for older systemd would be reasonable. |
Beta Was this translation helpful? Give feedback.
-
|
If other workarounds are required anyway, then I think it is fine to not revert the systemd unit only because of Ubuntu 18.04 an alike. A note somewhere makes sense, just not sure whether to put it, just a comment right into the systemd unit above |
Beta Was this translation helpful? Give feedback.
-
|
A documentation update to Running might work. At the end of Systemd usage, something like: If the version of systemd your distribution uses does not support the |
Beta Was this translation helpful? Give feedback.
-
|
Ah right, seems to fit best there, or additionally. Jürgen is quick: 5e71c53 |
Beta Was this translation helpful? Give feedback.
-
Quick and more succinct :) |
Beta Was this translation helpful? Give feedback.
-
First of all "systemd-analyze security" is not a security assesment tool, it only looks at the sandbox features built into systemd. It does not check the service itself. So it is safe to ignore these if you have a valid security concept for your system and a security concept needs to take in account the whole system, possible attack vectors, etc.; it´s not an easy task, just "switching on" some sandboxing in systemd gives a false sense of security.
Anyway, the new mympd.service file has several problems in my view:
It has DynamicUser=yes but then has User=mympd and Group=mympd specified. From the docs: "Note that if User= is specified and the static group with the name exists, then it is required that the static user with the name already exists. Similarly, if Group= is specified and the static user with the name exists, then it is required that the static group with the name already exists."
myMPD maintains files in /var/lib/mympd and /var/cache/mympd so it should have a proper static user anyway (like basically all other services do as well) who owns these.
DynamicUser aready implies ProtectSystem=strict, ProtectHome=read-only, PrivateTmp=yes and RemoveIPC=yes
but these are redundantly specified as well.
Availability of these options depend on the systemd version, e.g. on an older RedHat EL7 the script does not work at all, on EL8 it starts but myMPD does not appear to work correctly with all features. (I did not bother to debug that in detail as I see no need to use any of these options).
As it is, it's not generic, does not work "out of the box" in many cases and its usefullness is debateable (and untested). It is apparently targeted at one specific Debian distribution and therefore should be marked as such, optional for those who are willing to experiment with it, and not the default. It should not be enforced but be a deliberate choice and integration on a specific distribution should be done by the package maintainer. (Personally I use RedHat Enterprise compatible distributions, they have selinux on per default and can confirm that the service files RedHat ships sometimes have ProtectHome=yes and PrivateTmp=true but thats it.)
Beta Was this translation helpful? Give feedback.
All reactions