Dateirechte in gesamter Installation überprüfen

[reox]

Gibt es eine Möglichkeit zu überprüfen ob Dateien/Ordner von installierten Paketen andere Berechtigungen oder Besitzer haben und diese ggf wieder auf den Ursprungszustand zurücksetzen?
rpm kann sowas offenbar, gibt es das auch für debs? debsums kann ja nur den Inhalt der Datei überprüfen.

[ThorstenS]

Du kannst tripwire installieren. Das checkt periodisch deine Installation und schickt dir nen Report.
Aber das ist auf eine evtl. schon laufende Installation so nicht mehr anwendbar.
Du könntest aber ein (virtuelles) System mit den gleichen Paketen aufsetzen, dort tripwire seinen Job tun lassen und diese Datenbank dann auf das zu überprüfende System anwenden.
Ich hoffe es gibt einen einfacheren Weg

https://www.ostc.de/howtos/tripwire-HOWTO.html

[reox]

Ja na ein system erzeugen geht eh immer
Ich hab mich nur gefragt warum das bei rpm so einfach ist aber bei debs nicht. Vermutlich aber weil man beim deb das paket entpacken muss um die daten zu bekommen? Stehen beim rpm die permissions in einem metadatenfile? (So wie die hashes beim deb)

[reox]

Also ich glaube ein Problem ist, dass zwar im data.tar.xz die datei owner und rechte drin stehen, die aber durch die postinstall script noch verändert werden können.
Beispiel iputils-ping:

Code: Alles auswählen

$ tar tvf data.tar.xz
drwxr-xr-x root/root         0 2020-01-31 00:11 ./
drwxr-xr-x root/root         0 2020-01-31 00:11 ./bin/
-rwxr-xr-x root/root     73496 2020-01-31 00:11 ./bin/ping
drwxr-xr-x root/root         0 2020-01-31 00:11 ./usr/
drwxr-xr-x root/root         0 2020-01-31 00:11 ./usr/share/
drwxr-xr-x root/root         0 2020-01-31 00:11 ./usr/share/doc/
drwxr-xr-x root/root         0 2020-01-31 00:11 ./usr/share/doc/iputils-ping/
-rw-r--r-- root/root       389 2020-01-13 23:38 ./usr/share/doc/iputils-ping/NEWS.Debian.gz
-rw-r--r-- root/root      6132 2020-01-31 00:11 ./usr/share/doc/iputils-ping/changelog.Debian.gz
-rw-r--r-- root/root      4659 2020-01-13 23:38 ./usr/share/doc/iputils-ping/copyright
drwxr-xr-x root/root         0 2020-01-31 00:11 ./usr/share/man/
drwxr-xr-x root/root         0 2020-01-31 00:11 ./usr/share/man/man8/
-rw-r--r-- root/root      6550 2020-01-31 00:11 ./usr/share/man/man8/ping.8.gz
lrwxrwxrwx root/root         0 2020-01-31 00:11 ./bin/ping4 -> ping
lrwxrwxrwx root/root         0 2020-01-31 00:11 ./bin/ping6 -> ping
lrwxrwxrwx root/root         0 2020-01-31 00:11 ./usr/share/man/man8/ping4.8.gz -> ping.8.gz
lrwxrwxrwx root/root         0 2020-01-31 00:11 ./usr/share/man/man8/ping6.8.gz -> ping.8.gz

Allerdings kann /bin/ping je nach dem wie es konfiguriert ist auch u+s gesetzt haben (das passiert dann im postinstall). Oder es wird setcap verwendet, dann wäre es anders. (Die file capabilities und ACLs sind aber tatsächlich auch nochmal interessant...)
Also selbst wenn man die Information aus dem original Debian Paket zieht, kann sie nicht eindeutig sein.
Ist das der Grund warum es sowas nicht für Debian gibt?

[ThorstenS]

Ehrlich gesagt, hab ich dir auch nur geantwortet, weil ich dann die qualifizierteren Posts mitbekommen würde
Meine Recherchen haben leider auch keinen anderen Hinweise gefunden als tripwire. Ich hab die tripwire db früher per ro-NFS share eingebunden und dann per cron geprüft.

mittels apt-clone könntest du allerdings ein System schnell identisch aufsetzen, falls du losgelöst vom Produktivsystem die tripwire db erstellen willst.

[reox]

Ehrlich gesagt, hab ich dir auch nur geantwortet, weil ich dann die qualifizierteren Posts mitbekommen würde

*g* aber wie mir scheint, macht man es von anfang an einfach richtig (tripwire) oder eben gar nicht...
Ich würde vermuten, dass rechte/owner änderungen am system eher wenig probleme machen als zB ganze Dateiänderungen (welche man ja mit debsums/debsums2 checken kann).
Weil wenn jemand Rechte/Owner an Dateien so ändern kann, dass ein Schaden passieren kann, dann hatte der Angreifer ja sowieso schon Root rechte.
Klar, könnte er es zum geschickten exfiltrieren von Daten verwenden und so möglichst lange unterm Radar fliegen... Aber ja dann wäre natürlich tripwire schon besser um sowas zu erkennen.
Ich finds nur immer noch lustig, das rpm das kann und deb nicht

[MSfree]

Weil wenn jemand Rechte/Owner an Dateien so ändern kann, dass ein Schaden passieren kann, dann hatte der Angreifer ja sowieso schon Root rechte.

Och, das passiert nicht nur bei einem Angriff. Es gibt hier im Forum ja einige Threads, bei denen Benutzer versucht haben, das System mit chmod -R 777 / "besser benutzbar" zu machen, und das hinterher wieder rückgängig machen wollen.

[reox]

Weil wenn jemand Rechte/Owner an Dateien so ändern kann, dass ein Schaden passieren kann, dann hatte der Angreifer ja sowieso schon Root rechte.

Och, das passiert nicht nur bei einem Angriff. Es gibt hier im Forum ja einige Threads, bei denen Benutzer versucht haben, das System mit chmod -R 777 / "besser benutzbar" zu machen, und das hinterher wieder rückgängig machen wollen.

Der Angreifer ist hier der Benutzer halt selber

[Meillo]

Das Debian-Projekt koennte aber doch technisch die tatsaechlich installierten Dateirechte (also nach den Maintainer-Scripten) irgendwo speichern und ein Programm anbieten, das dagegen prueft. Pakete bei denen die Maintainer-Scripte bedingungsgebunden unterschiedliche Rechte setzen wird es nicht so viele geben, vermute ich.

So ein Projekt muesste halt ein DD angehen oder sonst jemand im Rahmen eines GSOC, beispielsweise. So gross wird der Aufwand nicht sein, vermute ich. Sicherlich koennte man dafuer an piuparts andocken oder sonst einem Service, der sowieso schon alle Pakete baut und installiert. Welche Dateien in jedem Paket stecken, weiss man schon, nur deren Rechte noch nicht, wobei Suid-Bits bereits erfasst werden. Es ist also gar nicht mehr so viel was noch fehlt.

Falls groesseres Interesse besteht, sollte man das Thema z.B. mal auf debian-devel@ ansprechen, vielleicht gibt's ja schon 'ne Moeglichkeit, die wir hier nur nicht sehen oder jemand anderes hat sich dazu auch schon Gedanken gemacht.

[MSfree]

So gross wird der Aufwand nicht sein, vermute ich.

Es wäre wohl relativ einfach, das Format der Dateien unter /var/lib/dpkg/info zu erweitern. Dort finden sich unter anderem .list-Dateien zu jedem installierten Paket, in denen die Dateilisten der Pakete gespeichert sind. Das wird meines Wissens zur Deinstallation benutzt. Nur beinhalten diese Dateien keine Informationen zu den Dateirechten und auch keine Informationen, die nachträglich durch setcap gesetzt wurden.

Hätte man diese erweiterten Informationen, könnte man ein Programm schreiben, das über die .list-Dateien iteriert und Dateinamen und -rechte mit denen auf der Platte vergleicht.

Im Grunde müßte man dazu die Maintainer des apt-Systems auffordern, das zu implementieren.

[Meillo]

So gross wird der Aufwand nicht sein, vermute ich.

Es wäre wohl relativ einfach, das Format der Dateien unter /var/lib/dpkg/info zu erweitern. Dort finden sich unter anderem .list-Dateien zu jedem installierten Paket, in denen die Dateilisten der Pakete gespeichert sind. Das wird meines Wissens zur Deinstallation benutzt. Nur beinhalten diese Dateien keine Informationen zu den Dateirechten und auch keine Informationen, die nachträglich durch setcap gesetzt wurden.

Hätte man diese erweiterten Informationen, könnte man ein Programm schreiben, das über die .list-Dateien iteriert und Dateinamen und -rechte mit denen auf der Platte vergleicht.

Im Grunde müßte man dazu die Maintainer des apt-Systems auffordern, das zu implementieren.

Dieser Ansatz haette zwei Nachteile:

1) Solche Dinge zu aendern ist meist eine grosse Sache, die Diskussionen und Zeit erfordert. Man muss ueberzeugen, kann nicht selber aktiv werden. Nur eine ``nette Idee'' zu haben reicht selten, dass so zentrale Dinge geaendert werden. Es muesste schon mit anderen (bedeutenderen) Plaenen zusammenfallen, auf die man dann gewissermassen mit aufspringen kann. (Das sind nur Vermutungen meinerseits. Vielleicht wuerde es tatsaechlich anders laufen.)

2) Da die Informationen auf dem System selber liegen kann man ein kompromittiertes System nicht dagegen pruefen.

Der Vorteil waere aber, dass bedingte Rechtesetzung bei der Installation kein Problem waere.

[reox]

Im Grunde sind ja Teile dieser Information schon im data.tar drin. Es ist halt nur ungeschickt das ganze deb herunterzuladen nur um an diese Info zu kommen. zB reicht es ja für die Hashes nur einen Teil des debs zu laden.
Aber man könnte das ja mal testen: Man installiert sich ein Basissystem und vergleicht dann die angegebenen Rechte von den debs mit dem System. So könnte man mal abschätzen wieviel in postinst scripten noch verändert wird.

[ThorstenS]

Genau, deswegen hatte ich dir apt-clone empfohlen. Das kann dir ein System genauso wieder zusammenstellen, wie das Produktivsystem.
Mit dem guten alten dpkg-repack kann es dir sogar wieder debs bauen, wenn das Paket nicht mehr in einem Repo verfügbar sein sollte (wie z.B. bpo-Kernel).
Ich hab das Gespann auf jedem System am Laufen, das noch nicht unter ansibles Ägide steht.