Was ist mit 'freebsd-update IDS' los?

[SolarCatcher]

Gestern hatte ich ein kleines Problem beim letzten Upgrade eines Servers von 14.0 auf 14.1. Daraufhin checkte ich per freebsd-update IDS, ob alles korrekt installiert wurde. Da hagelte es hunderte von Meldungen, wegen angeblicher fehlerhafter Dateirechte und auch einige Checksum-Fehler, inkl. bei Kernel und wenigen Kernel-Modulen. Das gefiel mir gar nicht.

Mit ZFS ging ich zurück zum vorhergehenden Boot Environment und machte den Upgrade erneut. Diesmal lief alles problemlos durch, die Meldungen von freebsd-update IDS blieben aber bestehen. Ich schaute dann, wie es auf meinen anderen FreeBSD-Systemen aussah: Überall dasselbe Bild; alle 14.1-Systeme zeigten massenhaft Probleme.

Seltsamerweise habe ich dazu weder im FreeBSD-Bugzilla noch via Google irgendwelche Hinweise gefunden. Wann hat denn freebsd-update IDS aufgehört sinnvolle Ergebnisse zu liefern? In der Vergangenheit hatte ich das ganz gelegentlich verwendet und schien noch alles prima.

Hinweis, für wer's nicht kennt: der IDS command bei freebsd-update soll laut Man-Page folgendes machen:

IDS Compare the system against a "known good" index of the installed release.

 

[Columbo0815]

Ich habe das Problem auch, direkt seit dem ersten Tag und eigentlich bei jedem Upgrade. So schlimm wie beim Upgrade auf 14.1 war es noch nie. Bislang habe ich die Berechtigungen immer händisch angepasst. Bei der Masse ist mir das aber zu viel. In einer ruhigen Minute (vermutlich im Jahr 2032) wollte ich ein Script basteln, das die Berechtigungen wie von IDS gewünscht anpasst.

 

[SolarCatcher]

Ich hätte erwartet, dass freebsd-update immer dieselbe Datengrundlage verwendet. Sowohl für's Updaten/Upgraden als auch für's Checken per IDS Befehl. Daher bin ich mir nicht im klaren, wer hier eigentlich "Recht hat": Update oder IDS? Warum sollte IDS besser "wissen", welche Berechtigungen eine Datei haben sollte.

Insbesondere frage ich mich das bei Dateien, bei denen IDS behauptet, dass (auch) die Checksumme nicht stimme: Wenn auf all meinen Systemen freebsd-update den Kernel mit einer bestimmten Checksumme installiert, woher stammt dann die Checksumme, die IDS erwartet? Und warum sollte ich auf jene vertrauen?

 

[Columbo0815]

Ich vermute (bin mir aber sicher, dass sich hier Leute tummeln, die das wissen), dass freebsd-update IDS gegen eine Neuinstallation prüft und beim Upgrade die Berechtigungen nicht korrekt gesetzt werden.

 

[medV2]

Ich vermute (bin mir aber sicher, dass sich hier Leute tummeln, die das wissen), dass freebsd-update IDS gegen eine Neuinstallation prüft und beim Upgrade die Berechtigungen nicht korrekt gesetzt werden.

This.

Ich hab ein 14.1 in einer VM installiert, das auch als 14.1 frisch installiert wurde und nur die Updates seit 14.1 Release nachgezogen. Da passt IDS und gibt nur die üblichen Verdächtigen raus (passwd/shells/group...).

 

[pit234a]

zwar benutze ich freebsd-update quasi seit der ersten Stunde, aber auf die Idee ein IDS zu versuchen, bin ich bisher noch nicht gekommen.
freebsd-update ist ein "einfaches" Shell-Script, man kann nachlesen, was es macht, ist mir aber nun zu viel.
Es hat eine config (die meist ignoriert wird und auch getrost ignoriert werden darf), in welcher man diverse Berechtigungen anpassen kann, also etwa auch dem Script erlauben, Symlinks zu überschreiben oder Dateiberechtigungen an zu passen.
Per Default verhält sich hier freebsd-update recht konservativ, wie sich das in meinen Augen auch so gehört.

Mein aktuelles System habe ich irgendwann in finsterer Vergangenheit mal versucht, an hardenedbsd an zu lehnen.
Aus praktischen Gründen heraus, habe ich seither zwar einige dieser Vorgaben wieder verworfen, aber grundsätzlich ist es doch cool, wenn freebsd-update funktioniert und meine alten Einstellungen hinsichtlich diverser Rechte bei behält und nicht überschreibt?
Wenn alles funktioniert, ist doch alles gut.
Dass IDS dann meckert, ist normal und gut, verlangt aber nicht unbedingt irgendwelche Aktionen von mir, zumindest, begreife ich das so.

 

[SolarCatcher]

@Columbo0815 @medV2 Vielen Dank, dann verstehe ich das ein bisschen besser.

@pit234a "IDS" steht normalerweise für "Intrusion Detection System". Dazu passt, dass die Man-Page sagt, dass Dein System mit einem "known-good" Zustand abgeglichen wird. Wenn dann lauter false-positive Warnhinweise kommen, dass Rechte nicht stimmen und vor allem, dass Checksums nicht mit dem "known-good" übereinstimmen, hat diese Funktion kaum noch einen Wert für mich.

Mein Kernel entspricht also nicht dem, was freebsd-update eigentlich erwartet!? Und was soll ich dann mit dieser Info machen, außer besorgt zu sein, dass entweder das Update nicht richtig durchgegangen ist (z.B. noch alte Dateien rumliegen) oder dass jemand meinen Kernel manipuliert hat.

Es geht hier meist nicht um Ordner und Dateien, die man selbst angelegt oder editiert hat (die gibt es auch, aber die kennt man, so was wie /etc/group). Es sind Systemdateien und da verstehe ich nicht, warum freebsd-update diesen nicht z.B. die Rechte erteilt, die der IDS command als "known-good" kennt.

 

[Andy_m4]

wer hier eigentlich "Recht hat":

Ich würde sagen, das freebsd-update IDS hier sogar eher Recht hat.
Ich weiß jetzt nicht, was hier genau die Ursache ist. Aber man muss dazu sagen, dass das Upgrade via freebsd-update ein gefühlt schon seit Jahren schwelendes Ärgernis ist. Möglicherweise wird das auch auf absehbare Zeit durch PkgBase ersetzt.

Im Prinzip reicht es fürs Upgrade, wenn man alle vorhandenen Dateien ersetzt durch das was in base.txz und kernel.txz enthalten ist (man muss nur gucken; manche Dateien sind immutable, die lassen sich dann nicht überschreiben ohne das entsprechende Bit mit chattr zu entfernen) welche man ja von https://download.freebsd.org/ftp/releases/ bekommt (z.B. für AMD64: https://download.freebsd.org/ftp/releases/amd64/14.1-RELEASE/).
Das einzige Problem sind die Konfig.-Dateien unter /etc die man entsprechend zusammenführen muss (wenn man das semi-automatisiert machen will, kann man dafür etcupdate nutzen).

Ähnlich kann man natürlich auch vor gehen, wenn man - wie in Deinem Fall - eine "ungültigen" Systemzustand fixen will.

 

[gadean]

Hm interessant, ich habe damit mal vor längerer Zeit gespielt (glaube 11.x oder 12.x?), da kamen auch nur die üblichen Verdächtigen (group/freebsd-update.conf/...). Jetzt habe ich das mal auf einem System, das ich mit 14.0 installiert und auf 14.1 aktualisiert hatte, ausgeführt und bekomme massig Meldungen das Checksummen nicht passen würden (nfscl.ko/ctl.ko/cfumass.ko/...).

Alles Dinge, die ich selbst nie angefasst habe, das ist schon merkwürdig.

 

[pit234a]

"IDS" steht normalerweise für "Intrusion Detection System". Dazu passt, dass die Man-Page sagt, dass Dein System mit einem "known-good" Zustand abgeglichen wird.

wenn aber ich selbst nun der "Intuder" bin?
Weil ich eben in der Vergangenheit schon einige Änderungen am System herbei geführt hatte, wie etwa zusätzliche SW zu installieren, die dann wiederum Änderungen vorgenommen hat usw...
Wie gesagt, es gibt die /etc/freebsd-update.conf und da kann man einige Dinge setzen und damit freebsd-update auch mehr erlauben, wie etwa Dateien zu ersetzen und so weiter.

Ansonsten habe ich Colin Percival <cperciva@FreeBSD.org> sehr angenehm und responsiv erlebt. Frag ihn doch einfach mal, was er dazu sagt.

 

[Columbo0815]

wenn aber ich selbst nun der "Intuder" bin?
Weil ich eben in der Vergangenheit schon einige Änderungen am System herbei geführt hatte, wie etwa zusätzliche SW zu installieren, die dann wiederum Änderungen vorgenommen hat usw...

Zusätzlich installierte Software ist ja nicht das, was freebsd-update IDS überprüft. Hier geht es rein um das Basissystem. Wenn du an dem rumpfuschst, dann weißt du das und wirst mit den Meldungen leben können/müssen. Soweit man Konfigurationen geändert hat, weiß man das ebenfalls. Das Dinge wie /etc/passwd etc. mitgeprüft werden (die ja automatisch immer abweichen), halte ich für überflüssig.

Wie gesagt, es gibt die /etc/freebsd-update.conf und da kann man einige Dinge setzen und damit freebsd-update auch mehr erlauben, wie etwa Dateien zu ersetzen und so weiter.

IMHO: Das worum es hier geht sind grundlegende Dinge, die von Haus aus funktionieren sollten. Ich sehe das (inzwischen) als Bug an.

 

[pit234a]

Zusätzlich installierte Software ist ja nicht das, was freebsd-update IDS überprüft. Hier geht es rein um das Basissystem.

ich meinte, dass ich womöglich Module selbst gebaut habe, weil die als Pakete unter Umständen nicht passen, was bei neuen Releases ja häufiger der Fall ist oder wenn ich bereits mehrere Updates auf meiner Maschine gelaufen sind und infolgedessen mancher Link eingeflossen ist, der auf derzeit aktuelle Versionen von Dateien zeigt, anstatt diese durch die neusten Versionen zu ersetzen.
Genau so etwas kann ich aber in der freebsd-update.conf regeln und wenn ich alte Dateien nicht auf löschen setze, bin doch ich selbst dafür verantwortlich und somit auch für das Verhalten des IDS-Kommandos.
Vielleicht sollte man bei Release-Wechseln grundsätzlich das Verhalten von freebsd-update überdenken und erklären, dass hier dann immer neue Dateien geschrieben werden möchten. Ich habe hierzu keine eigene Meinung und kann auch nicht abschätzen, wie wichtig dieses IDS überhaupt genommen werden kann.

Wie gesagt, Colin war mir gegenüber sehr höflich und bereit, Dinge zu erklären. So war ich zB der Meinung, dass die vielen Änderungen die am System vorgenommen werden sollen, nicht unbedingt gelistet werden müssten, weil das doch niemand liest und mittels q aus dem less ausbricht. Er meinte aber, dass ein Sysadmin sehr wohl die Möglichkeit haben sollte, alle Änderungen am System zuvor lesen zu können, weil es letztlich seine Verantwortung und nicht die Verantwortung eines Scripts ist, was da laufen soll.
Vielleicht hat er eine ähnlich gute Begründung für das Verhalten des IDS, die uns nun einfach nicht einleuchtet, vielleicht erkennt er auch einen BUG und mach sich an die Arbeit...

 

[Andy_m4]

Vielleicht hat er eine ähnlich gute Begründung für das Verhalten des IDS, die uns nun einfach nicht einleuchtet,

Meiner Ansicht nach verhält sich freebsd-update IDS hier korrekt. Das heißt, wenn Dateien z.B. falsche Checksums haben dann ist das, weil die nicht dem Release-Stand entsprechen.

Die Frage ist, warum der das Fall ist. Bei (modifizierten) Konfig.-Dateien usw. ist das natürlich einleuchtend. Bei executable-binarys des Base-Systems/Kernels eher nicht. Die sollten bei einem Upgrade immer hochgezogen werden.

Klar gibts auch da denkbare Ausnahmen. Zum Beispiel wenn man (teilweise was von) FreeBSD aus Quellen baut oder solche Geschichten.
Aber bei normalen (binären) Installation und der ausschließlichen Verwendung von freebsd-update für Updates/Upgrades gibts ja keinen vernünftigen Grund warum das anders sein sollte.
Im Gegenteil: Wenn da ein executable-binary nicht dem installieren Release-Stand entspricht bricht das meiner Ansicht nach sogar das Principle of least astonishment.

 

[pit234a]

Im Gegenteil: Wenn da ein executable-binary nicht dem installieren Release-Stand entspricht bricht das meiner Ansicht nach sogar das Principle of least astonishment.

klar, aber ist das denn überhaupt so?
Also findet hier freebsd-update tatsächliche Fehler?
Ich gebe zu, dass ich es in Folge dieses Threads nur zwei Mal benutzt habe und dann die überwiegende Anzahl von Fehlern auf Grund "permission ..." mal weg gefiltert habe und dann sieht das Ergebnis schon gar nicht mehr so dramatisch aus. Für mich selbst habe ich entschieden, dass die Permissions durchaus nicht dem entsprechen müssen, was bei einer Standard-Neu-Installation der Fall ist und auch die Verwendung von Symlinks statt echter Dateien für mich keinen Fehlerfall anzeigen.
Das kann man natürlich auch so deuten, dass die IDS-Funktion keinen wirklichen Sinn macht.
Ich weiß das nicht, wiederhole aber meinen Aufruf, direkt mal mit Colin zu reden.

 

[Andy_m4]

dass die Permissions durchaus nicht dem entsprechen müssen

Ja. Was so Dateiattribute inkl. Ownership/Permissions angeht, die man ja im weiteren Sinne auf als Konfiguration zählen kann, da kann man das so sehen.
Aber was so Checksummen angeht, was ja auch im Beitrag #9 angesprochen wurde, das ist dann noch mal eine andere Hausnummer. Da sehe ich jetzt keinen, warum die von executables (Programme, Treiber) nach einem Upgrade nicht auf Release-Stand sehen sollten (von den erwähnten Ausnahmen mal abgesehen).

 

[gadean]

@pit234a Auch fehlerhafte Berechtigungen können ein Risiko darstellen.
Wenn du zum Beispiel nicht alleine auf dem System bist und bei einer Binary, User das Recht haben diese zu überschreiben, könnte so einiges an Unfug anstellen.

 

[Columbo0815]

@pit234a Auch fehlerhafte Berechtigungen können ein Risiko darstellen.
Wenn du zum Beispiel nicht alleine auf dem System bist und bei einer Binary, User das Recht haben diese zu überschreiben, könnte so einiges an Unfug anstellen.

Dafür musst du nicht einmal alleine auf dem System sein. Es reicht ein User aus. Mal eben kurz weg vom PC oder eine unbekannte Lücke ausgenutzt. Zack, kann der User z.B. Dinge ausführen, die er normal nicht ausführen dürfte. Um den Vorschlag von @pit234a aufzugreifen: Ich habe schon seit dem Upgrade auf 14.1 auf der Liste, den guten Herrn anzumailen. Dafür brauche ich aber eine ruhige Minute. Ihn kenne ich nicht, habe aber selbst ebenfalls bislang fast durchweg positive Erfahrungen gemacht, wenn man die Leute direkt anschreibt.

 

[Andy_m4]

Auch fehlerhafte Berechtigungen können ein Risiko darstellen.

Ja. Können sie. Müssen es aber nicht notwendigerweise. Im Gegenteil. Man kann ja durchaus auch manuell Attribute setzen die die Sicherheit erhöhen gegenüber dem Standard-Install. Genauso wie es gute Gründe geben kann, warum man sie "lockerer" gesetzt hat.
Das das bei einem Upgrade nicht einfach (möglicherweise auch noch quiet) überschrieben wird finde ich ansich nachvollziehbar.

 

[gadean]

Deswegen schrieb ich ja auch "könnte".
Ich denke der Punkt hier ist, das wenn es ein Unterschied gibt solle man schauen ob man selbst dafür verantwortlich ist und es so in Ordnung ist oder ob ein unbefugter Dritter das System manipuliert hat.


PS: Ich hab gerade noch mal wegen dem Checksum Zeug geschaut und bin noch mehr verwirrt

Bei dem einen System (14.0 -> 14.1 -> p5) tauchen manche Einträge mehrfach auf, mit unterschiedlichen erwarteten Hashes

/boot/kernel/cfiscsi.ko has SHA256 hash a058eb1aefce8a6435a04394e7cb56d8ae1f032fd0f08a4fd96f2a0520dc17bf, but should have SHA256 hash 8ca3f4a03c86a425bc4f112e3a39ea739467e061e790cecece5b82a51502c552.
/boot/kernel/cfumass.ko has SHA256 hash cce553486437fe16a034d48dca4fb23a4c8e237f33a67170c0f38869de590ac7, but should have SHA256 hash c19a26de2e0ea837ec751581f89062897c6f84e336c72f4bb3fd045930117db3.
/boot/kernel/ctl.ko has SHA256 hash f7f14bd921c4f17061cf7e968ce54a017667e453a3695554f155ba938816ef01, but should have SHA256 hash 1efc90d3e29ddf924006c66c9eda0b2fa87926a5aeab9457bb27824fb021f2f7.
/boot/kernel/kernel has SHA256 hash 11a99e61888658653deb8175890ca410f8281030a8fd2b7eb88fdb3be62ed156, but should have SHA256 hash 040fdcee803ee595b41973de374551fd50c335c525142cdf6b4241af7a09e5ff.
/boot/kernel/kernel has SHA256 hash 11a99e61888658653deb8175890ca410f8281030a8fd2b7eb88fdb3be62ed156, but should have SHA256 hash 5ee83ee7de132fda8131db09feb53992c0a6856032dfac7f4a391ad7a928833a.
/boot/kernel/kernel has SHA256 hash 11a99e61888658653deb8175890ca410f8281030a8fd2b7eb88fdb3be62ed156, but should have SHA256 hash b88859dd52c51d1b6ec8095bbc9b5404b65bbacaa30ce345bf4bf6df37549021.
/boot/kernel/nfscl.ko has SHA256 hash bfcc4576b1821d4ba11a49c09a79df89fd868dba1fadf974f384314a0e28f7ad, but should have SHA256 hash f1b2e17f6ecdf46b579fb9276700e4e0ef821fff8c74f238b51e6a514e7ffa0d.
/boot/kernel/pf.ko has SHA256 hash b7489ae6ada8ad2263b07b35c97ae2409188cf5b62006eb5871d3cce3a8cffbf, but should have SHA256 hash 6e431705a51a8cf4b58c5c9a5d64a326b87f8dfa051c7858445bc1350e49cf87.
/boot/kernel/pf.ko has SHA256 hash b7489ae6ada8ad2263b07b35c97ae2409188cf5b62006eb5871d3cce3a8cffbf, but should have SHA256 hash 762363f060c4ddcdcb35a30d36f0eee7a3b0a6b90958fc7fc91d96e4faea7673.
/boot/kernel/zfs.ko has SHA256 hash 4e944f4cdd86d0ad0d1ac5f6c7eaf98f7e63db4c65c43a3f31e022c967162546, but should have SHA256 hash 96738b0cc44a1e09a00073a41e26e77a4608c07e392edbf43c3d8c0ce7d0fa20.

Auf einem frisch installierten 14.1 mit p5 Update, tauchen die Einträge nicht auf, also mal dort die Hashes abgegriffen und verglichen

SHA256 (/boot/kernel/cfiscsi.ko) = a058eb1aefce8a6435a04394e7cb56d8ae1f032fd0f08a4fd96f2a0520dc17bf
SHA256 (/boot/kernel/cfumass.ko) = cce553486437fe16a034d48dca4fb23a4c8e237f33a67170c0f38869de590ac7
SHA256 (/boot/kernel/ctl.ko) = f7f14bd921c4f17061cf7e968ce54a017667e453a3695554f155ba938816ef01
SHA256 (/boot/kernel/kernel) = 11a99e61888658653deb8175890ca410f8281030a8fd2b7eb88fdb3be62ed156
SHA256 (/boot/kernel/nfscl.ko) = bfcc4576b1821d4ba11a49c09a79df89fd868dba1fadf974f384314a0e28f7ad
SHA256 (/boot/kernel/pf.ko) = b7489ae6ada8ad2263b07b35c97ae2409188cf5b62006eb5871d3cce3a8cffbf
SHA256 (/boot/kernel/zfs.ko) = 4e944f4cdd86d0ad0d1ac5f6c7eaf98f7e63db4c65c43a3f31e022c967162546

Ehm? Die Hashes sind auf beiden Systemen gleich.
Man könnte meinen, IDS vergleicht hier die echten Hashes gegen welche von einer anderen Version oder ist komplett verwirrt?

 

[Andy_m4]

Ich hab gerade noch mal wegen dem Checksum Zeug geschaut und bin noch mehr verwirrt

Ja. Aber der Einblick ist tatsächlich sehr interessant. Scheint ja so, als wäre das Upgrade korrekt durchgelaufen und freebsd-update IDS macht irgendwas falsch. Was durchaus sein kann. Weil der Abgleich erfolgt nicht einfach gegen eine statische Datei in der alle Prüfsummen drin stehen, sondern das wird mehr oder weniger zusammengebastelt.
Möglicherweise gerät da (oder beim analysieren des IST-Zustands des Systems) wirklich was durcheinander. Müsste man sich mal näher angucken oder jemand fragen, der sich damit auskennt. :-)

 

[medV2]

Hoffen wir, dass bald der Switch vom Basesystem auf PKG kommt, dann haben wir pkg check -sa

 

[pit234a]

Weil der Abgleich erfolgt nicht einfach gegen eine statische Datei in der alle Prüfsummen drin stehen, sondern das wird mehr oder weniger zusammengebastelt.

und nicht nur einfach, sondern irgendwie gleich mehrfach, wenn ich das richtig sehe ("rm -f diff-OLD diff-NEW diff-add diff-rm").
Mir fehlt bei weitem die Energie und das Können dazu, aber im Grunde ist es ein "einfaches" Shell-Script das sich auch "relativ einfach" testen lässt.

Wenn es in älteren Versionen besser gelaufen ist, kann man vielleicht mal nach Änderungen sehen.
Oder, oder, oder...

jemand fragen, der sich damit auskennt. :-)

 

[pit234a]

Beitrag im Thema 'Welches Tool benutzt ihr, um /usr/ports zu aktualisieren?'

10 November 2024

Es wäre wirklich schön, wenn es nach inzwischen über zehn Jahren endloser Diskussion mal dazu kommen würde, dass das Basissystem paketiert wird. Aber es bis es so weit ist, kann man sich das Leben deutlich einfacher machen, indem man freebsd-rustdate - https://www.freshports.org/sysutils/freebsd-rustdate/ - nutzt. Es ist ganz wesentlich doll viele Universen schneller als das nervtötend langsame freebsd-update. Es ist schon mit komplexen Versionsupgrades einschließlich Reboots fertig, wenn freebsd-update noch im ersten Schritt der Metadatenauswertung rumkrebst.

• Yamagi

• 

btw: freebsd-rustdate check-sys zeigt mir eine Liste, die zumindest genauso umfangreich aussieht, wie sie freebsd-update ausgibt.
Die Einzelheiten habe ich mir nicht angesehen.
Das scheint aber zu bestätigen, dass freebsd-update hier gar nicht grundsätzlich falsch liegt.