[gssapi/gssproxy] b70043: Modernize systemd.m4 macro - gss-proxy - Fedora mailing-lists

25 Oct 2023


      Branch: refs/heads/main
  Home:   https://github.com/gssapi/gssproxy
  Commit: b70043186e4d323d29663783572ecf8fcbaf30d4
      https://github.com/gssapi/gssproxy/commit/b70043186e4d323d29663783572ecf8fcb...
  Author: David Härdeman david@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@hardeman.nu
Commit: 92e87872846c400598db30fb1759cd7c6f00db34
      https://github.com/gssapi/gssproxy/commit/92e87872846c400598db30fb1759cd7c6f...
  Author: David Härdeman david@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@hardeman.nu
Commit: 8d3cc9c5247ce3353f1f9a2ce63bda22cb78b287
      https://github.com/gssapi/gssproxy/commit/8d3cc9c5247ce3353f1f9a2ce63bda22cb...
  Author: David Härdeman david@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@hardeman.nu
Compare: https://github.com/gssapi/gssproxy/compare/d4004e67cb39...8d3cc9c5247c