https://bugzilla.suse.com/show_bug.cgi?id=1173749 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|meissner@suse.com |security-team@suse.de Summary|spice-vdagentd.service not |AUDIT-0: |enabled by default |spice-vdagentd.service not | |enabled by default -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1173749 https://bugzilla.suse.com/show_bug.cgi?id=1173749#c2 Matthias Gerstner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matthias.gerstner@suse.com --- Comment #2 from Matthias Gerstner --- systemd services do not require a security review per se. Adding a systemd service to the systemd presets to have it started automatically does require a review, however. The notion behind that is that we want to keep the default security on a high level. systemd services can for example be installed implicitly as dependencies of other packages. We usually don't want them to start up right away. It should be a conscious user decision to do so. The list of services that are automatically started is pretty short at the moment. So when you absolutely need this and have a convincing use case why it needs to be that way then we can do the AUDIT and add it to systemd-presents-branding-openSUSE. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1173749 https://bugzilla.suse.com/show_bug.cgi?id=1173749#c4 --- Comment #4 from Fabian Vogt --- (In reply to Matthias Gerstner from comment #2)

systemd services do not require a security review per se. Adding a systemd service to the systemd presets to have it started automatically does require a review, however.

The notion behind that is that we want to keep the default security on a high level. systemd services can for example be installed implicitly as dependencies of other packages. We usually don't want them to start up right away. It should be a conscious user decision to do so.

The udev rule starts the service, so effectively the service is automatically started, but only if the rule matches. That's why I'm asking whether an audit is required for that as well. (In reply to Matthias Gerstner from comment #3)

So are there any news here? Do you still needs this?

If no audit is neccessary, only the systemd bug remains, so feel free to reassign. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1173749 https://bugzilla.suse.com/show_bug.cgi?id=1173749#c6 --- Comment #6 from Fabian Vogt --- (In reply to Matthias Gerstner from comment #5)

(In reply to fvogt@suse.com from comment #4)

...

The udev rule starts the service, so effectively the service is automatically started, but only if the rule matches. That's why I'm asking whether an audit is required for that as well.

Is there a reason why the rule shouldn't match?

The service is for connecting to QEMU, so it only works if it's running in a VM with the appropriate guest device enabled.

It shows that we have a loophole in our security restrictions. udev rules can circumvent our systemd autostart restrictions. So maybe we should review this service here after all.

...

If no audit is neccessary, only the systemd bug remains, so feel free to reassign.

What do you mean by "the systemd bug"?

See comment 1. The udev rule has ENV{SYSTEMD_WANTS}="spice-vdagentd.socket" but the .socket unit is stopped on "systemctl isolate", even though the device (and therefore the wants relationship) is still there. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1173749 https://bugzilla.suse.com/show_bug.cgi?id=1173749#c8 --- Comment #8 from Fabian Vogt --- (In reply to Matthias Gerstner from comment #7)

(In reply to fvogt@suse.com from comment #6)

...

...

Is there a reason why the rule shouldn't match?

The service is for connecting to QEMU, so it only works if it's running in a VM with the appropriate guest device enabled.

Does it help to enable the service when the device is not enabled?

It would most likely just fail immediately.

...

See comment 1. The udev rule has ENV{SYSTEMD_WANTS}="spice-vdagentd.socket" but the .socket unit is stopped on "systemctl isolate", even though the device (and therefore the wants relationship) is still there.

Is this actually a systemd bug / something that systemd is likely to fix in the sense of this bug here?

I hope so, we'll see.

After a review we can add this service to the systemd presets. Hopefully there won't be any side effects ... the package is not installed by default, I hope, so for users not needing this nothing should change.

Yes, but I don't think that adding it to the preset is the right way actually. The udev rule is the right approach, just hits some corner cases... -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1173749 https://bugzilla.suse.com/show_bug.cgi?id=1173749#c10 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(systemd-maintaine | |rs@suse.de) | --- Comment #10 from Fabian Vogt --- (In reply to Matthias Gerstner from comment #9)

(In reply to fvogt@suse.com from comment #8)

...

Yes, but I don't think that adding it to the preset is the right way actually. The udev rule is the right approach, just hits some corner cases...

Okay then I suggest we keep this bug open for review. And you can create a split-off bug for systemd folks to address the separate issue of the `isolate` behaviour.

Done: bug 1175822 -- You are receiving this mail because: You are on the CC list for the bug.