Adjust SystemCallFilter= in rest-server.service (add `~@resources` and `~@privileged`)

Features and Ideas
1

systemd-analyze security rest-server.service

complains about that

 SystemCallFilter=~@resources

and

SystemCallFilter=~@privileged

are missing from examples/systemd/rest-server.service

[root@localhost ~]# systemd-analyze security rest-server.service | head -6
  NAME                                                        DESCRIPTION                                                                                         EXPOSURE
✓ SystemCallFilter=~@swap                                     System call allow list defined for service, and @swap is not included                               
✗ SystemCallFilter=~@resources                                System call allow list defined for service, and @resources is included (e.g. ioprio_set is allowed)      0.2
✓ SystemCallFilter=~@reboot                                   System call allow list defined for service, and @reboot is not included                             
✓ SystemCallFilter=~@raw-io                                   System call allow list defined for service, and @raw-io is not included                             
✗ SystemCallFilter=~@privileged                               System call allow list defined for service, and @privileged is included (e.g. fchown is allowed)         0.2
[root@localhost ~]#

I tested the following patch

--- a/examples/systemd/rest-server.service
+++ b/examples/systemd/rest-server.service
@@ -57,6 +57,8 @@ RestrictRealtime=true
 # if your service crashes with "code=killed, status=31/SYS", you probably tried to run linux_i386 (32bit) binary on a amd64 host
 SystemCallArchitectures=native
 SystemCallFilter=@system-service
+SystemCallFilter=~@resources
+SystemCallFilter=~@privileged
 
 # Additionally, you may wish to use some of the systemd options documented in
 # systemd.resource-control(5) to limit the CPU, memory, file-system I/O and

in the same was as the test was performed in

It seems to work.

2

Could you move the suggestion over to Github? It’s too easy to loose track of such suggestions on the forum.

3

Currently
systemd-analyze security rest-server.service
lists the following items as having a non-null exposure:

exposure name description
0.5 PrivateNetwork= Service has access to the host’s network
0.3 RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets
0.2 IPAddressDeny= Service does not define an IP address allow list
0.2 SystemCallFilter=~@privileged System call allow list defined for service, and @privileged is included (e.g. fchown is allowed)
0.2 SystemCallFilter=~@resources System call allow list defined for service, and @resources is included (e.g. ioprio_set is allowed)
0.1 UMask= Files created by service are group-readable by default
0.1 DeviceAllow= Service has a device ACL with some special devices: char-rtc:r
0.1 ProcSubset= Service has full access to non-process /proc files (/proc subset=)
0.1 RootDirectory=/RootImage= Service runs within the host’s root directory

What do you think about the idea that I for each line create a feature request in the GitHub repo restic/rest-server

with for example the text

systemd-analyze security rest-server.service

lists 

SystemCallFilter=~@privileged

as not being set as an exposure of 0.2.
Follow the suggestion or document why the suggestion should not be followed.

?

A sidenote: The Markdown table was generated with the following commands:

echo  "| exposure | name | description |"
echo  "| --- | ---- | --- |"
systemd-analyze security --json=short rest-server.service | \
   jq  '[ .[] | .name |= gsub("\\|";"\\|";"i") ]' | \
   jq  '[ .[] | .description |= gsub("\\|";"\\|";"i") ]' | \
   jq -r '[ .[] | select(.exposure != null ) | . ] |  sort_by(.exposure) | reverse | .[] | "| \(.exposure) | \(.name) |  \(.description) |"'
4

Please don’t. Just create a single pull request. I’m also not sure which options actually make sense for rest-server, it’s not necessary to actually enable each option in existence. For example RootDirectory would primarily complicate the deployment.

5

Okay, I just created created the PR