Systemd service refuses to run on linux-hardened

added priority3-normal severity4-low statusunconfirmed labels

assigned to @freswa, @toolybird, @antiz, and @gromit

Seems expected/normal. One of the consequences of locking things down.

The program itself doesn't need user namespaces to run; the provided service configuration does. The old service (back when this was an AUR package) was able to run just fine.

@vladaviedov Does the service runs fine if you remove/comment RestrictNamespaces=true?

The old service (back when this was an AUR package) was able to run just fine.

By the way, the systemd service was added 8 months ago back when this package was still in the AUR and it hasn't been modified in any significant way since then. So, unless I'm missing something, there's no reason that the service itself behaved differently back when this was still an AUR package.

@antiz

Does the service runs fine if you remove/comment RestrictNamespaces=true

Just tested all of the options marked as "Hardening" and the offending ones are:

ProtectKernelModules=true
PrivateDevices=true

These settings give an error about user namespaces, but the service seems to run:

PrivateTmp=true
ProtectSystem=full
ProtectControlGroups=true
ProtectKernelTunables=true

By the way, the systemd service was added 8 months ago back when this package was still in the AUR

Interesting. I was using protonmail-bridge-nogui before, which looks like had a different service.

Just tested all of the options marked as "Hardening" and the offending ones are:
ProtectKernelModules=true
PrivateDevices=true
These settings give an error about user namespaces, but the service seems to run:
PrivateTmp=true
ProtectSystem=full
ProtectControlGroups=true
ProtectKernelTunables=true

@vladaviedov Thanks for the investigation!

@carsme Any thoughts on dropping/adapting those parameters to allow the service to run out the box for linux-hardened users?
I'm personally a bit torned on this one... Removing hardening for everyone "just" for linux-hardened users feel a bit wrong but, as I'm not the one that implemented those hardened parameters in the service configuration, I'm not sure about the eventual implications.

If anything, I guess linux-hardened users can systemctl edit the service to make it run properly. After all, the wiki clearly says that "it should be noted that several packages will not work when using this kernel" (or at least not "as-is" in that specific case).

What do you think?

Interesting. I was using protonmail-bridge-nogui before, which looks like had a different service.

@vladaviedov Yeah, this was a different/separate package with it's own service configuration (which, I assume, didn't have those hardened parameters/options).

@carsme Any thoughts on dropping/adapting those parameters to allow the service to run out the box for linux-hardened users?

I'm afraid I'm no expert on service-hardening - I think I copied these parameters from another package when @anthraxx suggested I'd harden the service-files I packaged in the AUR. Since the service runs as a regular user rather than root, I wonder how important the hardening actually is for this particular service.

I'm personally a bit torned on this one... Removing hardening for everyone "just" for linux-hardened users feel a bit wrong but, as I'm not the one that implemented those hardened parameters in the service configuration, I'm not sure about the eventual implications.

I'm torn as well. My thoughts are that now when the hardening is in-place and the package is working as intended with the linux kernel I'm leaning towards keeping it. But I would be of the opposite opinion if someone more knowledgeable than me pointed out that the hardening is redundant/inappropriate.

My thoughts are that now when the hardening is in-place and the package is working as intended with the linux kernel I'm leaning towards keeping it.

My thoughts as well. Since it works fine with the other kernel packages officially supported (as far as I know), I think it's safe to say that this issue is specific to linux-hardened.
In my opinion, such behaviors could be "expected" with this kernel (as Doug said and as warned in the wiki).

Since @vladaviedov was able to find the "offending" options, I think it's reasonable to point linux-hardened users to systemctl edit the service file accordingly (should only be needed once).

Allow me to close this issue. Thanks for the report though!

I'm not sure I fully agree with the reasoning, as u privileged userns switches are also a patch in our vanilla Linux kernel, just with a different stock default. So users that turn off unprivileged userns in the default kernel experience the very same issue.

If you as package maintainers agree on this stance, please state so and I'm happy to invest some time and consider the offending knobs related to the overall service security of this package and can provide you a recommendation if we should nevertheless ignore it, or change it.

@anthraxx If you are fine taking a look at this, please do! I have no doubt the reasoning is a bit flawed. Just like @carsme said previously, I'm also no expert on service-hardening... So I'd be glad having an input/recommandation from someone with more experience on that matter

I'm re-opening the issue.

added scopebug statusconfirmed labels and removed statusunconfirmed label

assigned to @carsme and unassigned @freswa, @toolybird, and @gromit

closed

added resolutioncompleted label

reopened

mentioned in issue fluidsynth#2 (closed)

Systemd service refuses to run on linux-hardened

Description:

Additional info:

Steps to reproduce:

Child items ...

Activity

Admin message

Systemd service refuses to run on linux-hardened

Description:

Additional info:

Steps to reproduce:

Activity