[gssapi/gssproxy] b70043: Modernize systemd.m4 macro
by David Härdeman
Branch: refs/heads/main
Home: https://github.com/gssapi/gssproxy
Commit: b70043186e4d323d29663783572ecf8fcbaf30d4
https://github.com/gssapi/gssproxy/commit/b70043186e4d323d29663783572ecf8...
Author: David Härdeman <david(a)hardeman.nu>
Date: 2023-10-25 (Wed, 25 Oct 2023)
Changed paths:
M external/systemd.m4
Log Message:
-----------
[gssproxy] Modernize systemd.m4 macro
libsystemd-daemon hasn't been a thing since systemd 209 was
released (February 2014, before RHEL 7). And the thing we really
want to look for is libsystemd, that's it.
Signed-off-by: David Härdeman <david(a)hardeman.nu>
Commit: 92e87872846c400598db30fb1759cd7c6f00db34
https://github.com/gssapi/gssproxy/commit/92e87872846c400598db30fb1759cd7...
Author: David Härdeman <david(a)hardeman.nu>
Date: 2023-10-25 (Wed, 25 Oct 2023)
Changed paths:
M contrib/gssproxy.spec.in
M src/gp_common.h
M src/gp_init.c
M src/gp_mgmt.c
M src/gp_util.c
M systemd/gssproxy.service.in
M systemd/gssuserproxy.service.in
Log Message:
-----------
[gssproxy] Change daemon to Type=notify with systemd
This avoids the need for daemonization, pid files, etc and also provides nicer
output from systemctl. The notify integration is already prepared to work with
Type=notify-reload (which is a bit too recent to make the default at the
moment, requires systemd 253+).
With this patch applied:
root@qtest1:~# systemctl status gssproxy
● gssproxy.service - GSSAPI Proxy Daemon
Loaded: loaded (/lib/systemd/system/gssproxy.service; enabled; preset: enabled)
Active: active (running) since Fri 2023-10-20 12:59:32 CEST; 4s ago
Main PID: 58516 (gssproxy)
Status: "Running, 1 service(s) configured"
...
root@qtest1:~# ls -1 /etc/gssproxy/
24-nfs-server.conf
gssproxy.conf
root@qtest1:~# vi /etc/gssproxy/50-nfs-client.conf
root@qtest1:~# ls -1 /etc/gssproxy/
24-nfs-server.conf
50-nfs-client.conf
gssproxy.conf
root@qtest1:~# systemctl reload gssproxy
root@qtest1:~# systemctl status gssproxy
● gssproxy.service - GSSAPI Proxy Daemon
Loaded: loaded (/lib/systemd/system/gssproxy.service; enabled; preset: enabled)
Active: active (running) since Fri 2023-10-20 12:59:32 CEST; 1min 39s ago
Process: 58576 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 58516 (gssproxy)
Status: "Running, 2 service(s) configured"
...
Signed-off-by: David Härdeman <david(a)hardeman.nu>
Commit: 8d3cc9c5247ce3353f1f9a2ce63bda22cb78b287
https://github.com/gssapi/gssproxy/commit/8d3cc9c5247ce3353f1f9a2ce63bda2...
Author: David Härdeman <david(a)hardeman.nu>
Date: 2023-10-25 (Wed, 25 Oct 2023)
Changed paths:
M systemd/gssproxy.service.in
Log Message:
-----------
[gssproxy] Harden systemd .service file
Most of the configuration options should be straightforward.
The previous version of the .service file contained a comment that
NoNewPrivileges=yes breaks the ability to open a socket under
/var/lib/gssproxy. That does not appear to be correct because ProtectClock=yes
was already set, which enables NoNewPrivileges.
Furthermore, the comment for ProtectKernelTunables also appears to be
incorrect, because it doesn't make all of /proc read-only (it's only
/proc/sys/, /sys/, /proc/sysrq-trigger, /proc/latency_stats, /proc/acpi,
/proc/timer_stats, /proc/fs and /proc/irq, see man systemd.exec(5)), so
/proc/net/rpc/use-gss-proxy is still writeable. Perhaps it was a mixup with
ProtectProc?
With this applied, the "systemd-analyze security gssproxy" score goes from 8.4
(EXPOSED) to 1.7 (OK).
Tested with nfs-kernel-server, some more testing in other scenarios might still
be necessary. Also, note that this expects all RW data to be stored under
/var/lib/gssproxy, /root, /home or /run/user.
Signed-off-by: David Härdeman <david(a)hardeman.nu>
Compare: https://github.com/gssapi/gssproxy/compare/d4004e67cb39...8d3cc9c5247c
6 months
