Hallo Liste,
Ich habe ein unerwartetes verhalten bei der Software Splunk Universal Forwarder in Verbindung mit systemd und Capabilities. Bei der Installation der 9.0.x Version wird ein Systemd Service file angelegt.
[Unit] Description=Systemd service file for Splunk, generated by 'splunk enable boot-start' After=network-online.target Wants=network-online.target
[Service] -->schnipp<-- User=splunk Group=splunk NoNewPrivileges=yes AmbientCapabilities=CAP_DAC_READ_SEARCH -->schnipp<-- [Install] WantedBy=multi-user.target
Wenn er Dienst startet hat er durch CAP_DAC_READ_SEARCH Lesezugriff auf alle Dateien im Filesystem. Ob das gut oder schlecht ist lassen wir mal dahingestellt.
Wenn ich eine ältere Version (8.2.*) der Software installiere sind die Werte:
NoNewPrivileges=yes AmbientCapabilities=CAP_DAC_READ_SEARCH
per default nicht gesetzt. Wenn ich sie hinzufüge, ein systemctl daemon-reload ausführe kann die Software nicht auf Dateien zugreifen, auf welche der Technische Nutzer Leseberechtigung hat.
Das verwundert mich. Ich habe geprüft ob die capabilites wirklich beim Dienst ankommen - sieht erstmal gut aus:
[root@ip-10-53-1-118 local]# systemctl status SplunkForwarder |grep -i PID Main PID: 3527 (splunkd) └─3552 [splunkd pid=3527] splunkd --under-systemd --systemd-delegate=yes -p 8089 _internal_launch_under_systemd [process-runner] Jun 13 13:26:04 ip-10-53-1-118 splunk[3527]: 2023-06-13 13:26:04.083 +0000 splunkd started (build 4a20fb65aa78) pid=3527
[root@ip-10-53-1-118 local]# getpcaps 3527 3527: cap_dac_read_search=eip
Any hints? Für mich sieht ja fast so aus, als wenn das Setzen der Capability nicht ausrecht und die Software das noch aktiv unterstützen muss?!
Besten Gruss,
Andreas
Hallo Andreas,
On Tue, Jun 13, 2023 at 15:29:02 +0200, Andreas Roth wrote:
[systemd-Unit non-root mit Capabilities]
Wenn ich eine ältere Version (8.2.*) der Software installiere sind die Werte:
NoNewPrivileges=yes AmbientCapabilities=CAP_DAC_READ_SEARCH
per default nicht gesetzt. Wenn ich sie hinzufüge, ein systemctl daemon-reload ausführe kann die Software nicht auf Dateien zugreifen, auf welche der Technische Nutzer Leseberechtigung hat.
Das verwundert mich. Ich habe geprüft ob die capabilites wirklich beim Dienst ankommen - sieht erstmal gut aus:
[...]
[root@ip-10-53-1-118 local]# getpcaps 3527 3527: cap_dac_read_search=eip
Mit getpcaps kannst Du nicht sehen, ob die Capabilities auch im Ambient-Set gesetzt sind. Besser direkt in /proc greppen:
# grep Cap /proc/PID/status
Das folgende Minimalbeispiel hat bei mir in einem Debian 11 Livesystem funktioniert:
# Put this in /etc/systemd/system/ # telnetd is actually busybox telnetd: # CONFIG_TELNETD=y # CONFIG_FEATURE_TELNETD_STANDALONE=y # Shell provided by telnet login runs as unprivileged user but has # CAP_DAC_READ_SEARCH, thus it can read any file/dir. # After login, run # $ grep Cap /proc/$$/status # to verify CAP_DAC_READ_SEARCH is allowed in ambient set. [Unit] Description=telnetd
[Service] User=user Group=user NoNewPrivileges=yes AmbientCapabilities=CAP_DAC_READ_SEARCH ExecStart=/usr/local/bin/telnetd -F -p 3333 -l /bin/bash
[Install] WantedBy=multi-user.target
Gruss, Christian
Hallo Liste,
nach ein paar Bier und etwas Rumpro"bier"en hat sich folgendes rausgestellt:
Obwohl der Splunk-Prozess die korrekte Capability in den entsprechenden Sets hat, gibt es den Fehler, weil er *vor* dem eigentlich open() auf die Datei ein access() respektive faccessat() darauf loslaesst.
Die Capability CAP_DAC_READ_SEARCH erlaubt zwar open()/openat() auf eine sonst nicht lesbare Datei, aber die access()-Familie liefert einen Fehler. Ob das jetzt inkonsistentes Verhalten des Kernels ist, sei mal dahingestellt.
Simples Testprogramm, schlaegt trotz CAP_DAC_READ_SEARCH fehl:
--------------------------------------------------------------------- #define _POSIX_C_SOURCE 200809L
#include <stdio.h> #include <unistd.h>
int main() { int ret;
ret = access("/var/log/kern.log", R_OK);
if (-1 == ret) { perror("access"); return 1; }
return 0; } ---------------------------------------------------------------------
Gruss, Christian
Hi,
On Wed, Jun 28, 2023 at 10:02:37PM +0200, Christian Perle wrote:
nach ein paar Bier und etwas Rumpro"bier"en hat sich folgendes rausgestellt:
Obwohl der Splunk-Prozess die korrekte Capability in den entsprechenden Sets hat, gibt es den Fehler, weil er *vor* dem eigentlich open() auf die Datei ein access() respektive faccessat() darauf loslaesst.
nice work... ich vermute da war neben Bier auch strace involviert :-)
Die Capability CAP_DAC_READ_SEARCH erlaubt zwar open()/openat() auf eine sonst nicht lesbare Datei, aber die access()-Familie liefert einen Fehler. Ob das jetzt inkonsistentes Verhalten des Kernels ist, sei mal dahingestellt.
Ich finde dieses access()/open() Pattern im userspace ist generell kaputt. Das ist ja eh immer anfällig für race conditions.
Grüsse Andreas
Hi,
On 28/06/2023 22:28, Andreas Fett wrote:
On Wed, Jun 28, 2023 at 10:02:37PM +0200, Christian Perle wrote:
Die Capability CAP_DAC_READ_SEARCH erlaubt zwar open()/openat() auf eine sonst nicht lesbare Datei, aber die access()-Familie liefert einen Fehler. Ob das jetzt inkonsistentes Verhalten des Kernels ist, sei mal dahingestellt.
Ich finde dieses access()/open() Pattern im userspace ist generell kaputt. Das ist ja eh immer anfällig für race conditions.
Die access() calls ignorieren zum Teil auch Flags auf Mount-Ebene, ACLs, Superuser-Rechte etc. Es werden nur stupide die Bits der klassischen Zugriffsrechte geprüft. Es gibt Race Conditions, Security Considerations und angeblich auch versteckte Drachen, die Hunger auf ahnungslose Programmierer haben.
Die man-Page klingt nicht gerade wie eine uneingeschränkte Empfehlung durch die Kernelentwickler.
Kurz: man kann nur davon abraten access() zu benutzen.
Konrad
Hallo,
On Thu, Jun 29, 2023 at 07:55:30PM +0200, Konrad Rosenbaum wrote:
Die man-Page klingt nicht gerade wie eine uneingeschränkte Empfehlung durch die Kernelentwickler.
Oh. Hatte das noch gar nicht nachgeguckt, aber in der Tat, nicht nur die Linux manpage sondern auch die von Open-/Net-/Freebsd und sogar die von der Opengroup (aka POSIX) enthalten unterschiedlich deutliche Formen von "dont't use this".
Kurz: man kann nur davon abraten access() zu benutzen.
Ja... Antipattern.
Grüsse Andreas
lug-dd@mailman.schlittermann.de
-
Andreas Fett -
Andreas Roth -
Christian Perle -
Konrad Rosenbaum