I don't think this daemon is a likely target of attack.  But I think it's
goot to try and keep the overall score from "systemd-analyze security" as low
as possible.

My tests show that it seems to work OK with the following settings.  I think
that more testing is needed before adding all of them.  But some of them are
low risk like restricting to AF_UNIX and restricting capabilities and the
system call architecture.

[Service]
CapabilityBoundingSet=CAP_SYS_ADMIN
# needs @resources
SystemCallFilter=~@cpu-emulation @debug @raw-io @reboot @swap @obsolete @privileged
SystemCallArchitectures=native
UMask=077
NoNewPrivileges=true
ProtectKernelLogs=true
ProtectControlGroups=true
ProtectKernelModules=true
RestrictNamespaces=true
RestrictSUIDSGID=true
LockPersonality=true
ProtectHostname=true
ProtectKernelTunables=true
RestrictAddressFamilies=AF_UNIX

Hello Russel Cooker,

I think this is a good idea, but I think it's a much better idea if we
have upstream maintain this along the code changes they make which might
influence what settings you need/want. Upstream provides the
udisks2.service file after all.

Could you create an upstream issue or even pull request?

https://github.com/storaged-project/udisks
[...]

I'm guessing a topic for discussion upstream will be in which systemd
version respective option was introduced, what version is the minimum
required one upstream thinks is acceptable setting as a requirement and
making sure unsupported options is gracefully ignored.
If you know the answer to any of this for the above options it might be
good to include from the get go.

Regards,
Andreas Henriksson