tlshd: harden systemd .service file

[Alphix]

This brings the "systemd-analyze security tlshd" score from 9.5 down to 1.7.

Tested on a client and a server using a NFS mount with "xprtsec=mtls".

[oracle-contributor-agreement[bot]]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA). The following contributors of this PR have not signed the OCA:

• PR author: david@hardeman.nu (@Alphix)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[Alphix]

(My OCA application is pending)

[oracle-contributor-agreement[bot]]

Thank you for signing the OCA.

[Alphix]

Might want CAP_DAC_OVERRIDE as well, in case certs wouldn't be readable to the root user otherwise....

[chucklever]

I'm looking for some review from distribution security teams.

But also, we need more rationale than improving the score on a tool -- there are a lot of new settings being added here. What was the default for each setting, and what actual security improvement does each change bring?

[chucklever]

Closing: No response from OP on questions above, and no action from security reviewers.

[Alphix]

I'm looking for some review from distribution security teams.

But also, we need more rationale than improving the score on a tool -- there are a lot of new settings being added here. What was the default for each setting, and what actual security improvement does each change bring?

Basically, the changes make the whole file-system read-only, makes most special-purpose file systems read-only or hidden, disables the ability for the daemon to communicate using anything more than the netlink socket it uses to communicate with the kernel....more specifically:

ProtectSystem=strict

Makes the whole file system hierarchy read-only (except /dev, /proc, /sys)

PrivateDevices=yes

Makes a minimum number of devices available under /dev

PrivateIPC=yes

Sets up a separate System V IPC namespace.

PrivateTmp=yes

Sets up a separate private mount for /tmp and /var/tmp

ProtectHome=tmpfs

Makes /home, /root and /run/user empty and inaccessible

ReadWritePaths=

Disallows write access to any paths in the file system

ProtectHostname=yes

Disallows changing the hostname

ProtectClock=yes

Disallows changing the host clock

ProtectKernelTunables=yes

Makes a bunch of kernel variables under /proc and /sys read-only

ProtectProc=invisible

Hides processes from other users under /proc/PID

ProcSubset=pid

All files and directories not directly associated with process management and introspection are made invisible in /proc

ProtectKernelModules=yes

Disallows loading kernel modules

ProtectKernelLogs=yes

Disallows access to the kernel log ring buffer

ProtectControlGroups=yes

Makes Linux cgroups read-only

RestrictAddressFamilies=AF_UNIX AF_NETLINK

Limits the allowed socket families to the ones listed above

RestrictNamespaces=yes

Restricts access to Linux namespace functionality

LockPersonality=yes

Locks down the personality(2) system call

MemoryDenyWriteExecute=yes

Disallows creating memory mappings which are writable and executable

RestrictRealtime=yes

Disallow enabling realtime scheduling

RestrictSUIDSGID=yes

Disallow setting SUID/SGID bits on files

PrivateMounts=yes

The daemon will be run in a private mount namespace (meaning that any mounts performed by the daemon will not be visible in the host's main file system view)

SystemCallFilter=@system-service

Limits the allowed system calls to "a reasonable set of system calls used by common system services"

SystemCallErrorNumber=EPERM

The error to return for disallowed system calls

SystemCallArchitectures=native

Limits the allowed system calls to the ones for the arch which systemd is compiled for

NoNewPrivileges=yes

The daemon cannot gain new privileged through execve (e.g. by running SGID/SUID binaries)

CapabilityBoundingSet=CAP_NET_ADMIN

Capabilities to include in the capability bounding set (capabilities(7)), CAP_NET_ADMIN is necessary for the netlink socket

IPAddressDeny=any

Disallow IP based communication from the daemon

@chucklever: not sure if that answers your question?

[chucklever]

@chucklever: not sure if that answers your question?

It doesn't. I'm looking for information about why each option change is needed and appropriate for tlshd in particular. Some of these look obvious, some look unnecessary, some look like they might impact the operation of tlshd (IPAddressDeny=any for a daemon that does TLS handshakes with remote hosts seems.... strange).