Howdee, folks!
I have made it a good practice of mine to use systemd sandboxing features for my systemd units.
This was my systemd unit for Mattermost up until 7.8.1:
[Unit]
Description=Mattermost is an open source, self-hosted Slack-alternative
After=syslog.target network.target postgresql.service
Before=apache2.service
[Service]
Type=simple
User=mattermost
Group=mattermost
ExecStart=/opt/mattermost/bin/mattermost
WorkingDirectory=/opt/mattermost
ReadWritePaths=/opt/mattermost /opt/mattermost-data
MemoryDenyWriteExecute=true
LockPersonality=true
# AF_UNIX needed for plugins to work
RestrictAddressFamilies=AF_INET AF_NETLINK AF_UNIX
NoNewPrivileges=true
UMask=0077
RemoveIPC=true
ProcSubset=pid
RestrictSUIDSGID=true
RestrictNamespaces=true
RestrictRealtime=true
PrivateDevices=true
PrivateTmp=true
PrivateUsers=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectProc=invisible
ProtectHome=true
ProtectSystem=strict
ProtectClock=true
ProtectControlGroups=true
ProtectHostname=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~@debug @privileged @resources
CapabilityBoundingSet=
[Install]
WantedBy=multi-user.target
When upgrading my instance from 7.8.1 to 7.9.0, Mattermost didn’t start. Kernel logs indicated an issue with a syscall:
Mar 16 14:12:30 HOSTNAME kernel: [1428827.030625] audit: type=1326 audit(1678972350.266:4): auid=4294967295 uid=1009 gid=1008 ses=4294967295 subj=unconfined pid=2999066 comm="mattermost" exe="/opt/mattermost/bin/mattermost" sig=31 arch=c000003e syscall=160 compat=0 ip=0x40440e code=0x80000000
It seems starting with 7.9.0, Mattermost needs the @resources system call set. Modifying my unit accordingly solved the issue:
Before:
SystemCallFilter=@system-service
SystemCallFilter=~@debug @privileged @resources
After:
SystemCallFilter=@system-service
SystemCallFilter=~@debug @privileged
Now… I do realize that sandboxing features are very likely nothing you currently test for, when releasing Mattermost. That being said, I was wondering whether this could somehow be made part of your internal testing, as, from a technical perspective, this was a change that has not been mentioned in the changelogs.
I haven’t yet seen a software doing that, so Mattermost is in good company there.
But maybe Mattermost wants to lead by example here, so I’d like you to consider making this part of the changelog in the future.
Having spent a few minutes thinking about that, I’m fairly certain it should be trivial to make this part of an automated testing pipeline.
Since I assume that usually a Mattermost developer does not go about his/her daily business and suddenly decides “Well, today I’m gonna introduce a new system call to Mattermost”, I think this is usually introduced by using some Go functionality that has not been used before, thus requiring a new set of system calls without the developer necessarily being aware of that.
Well… that’s it for my first post here 
Happy to hear some feedback from people running or building Mattermost.
Cheers
Thomas