Hallo David, hallo Leute, Am Mittwoch, 9. Februar 2005 04:38 schrieb David Haller:
Am Tue, 08 Feb 2005, Christian Boltz schrieb:
Hallo David, hallo Sapheriel, hallo Leute,
(David, das ist einer der seltenen Fälle, in denen ich Dir widerspreche ;-)
Schoen, dass es das auch gibt :) Sowas kommt ja nicht allzu oft vor, selbst, wenn ich mich mal in Gebiete begebe, wo ich wenig Ahnung habe.
BTW an alle: ich weiss nicht, wie ich auf die Leser hier wirke, ich kann da nur aus den Mails ableiten, aber wenn ich mal daneben liege, dann will ich korrigiert werden bzw. einen Widerspruch bekommen.
Dein Wunsch sei Dir erfüllt ;-)
Am Dienstag, 8. Februar 2005 20:31 schrieb David Haller: [Dateiowner reparieren]
/sbin/conf.d/SuSEconfig.permissions
setzt die in /etc/permissions* festgelegten Rechte.
Dann noch ein 'rpm --setugids -a'
Falsche Reihenfolge ;-) Zuerst rpm --setugids und dann SuSEconfig.permissions, da SuSEconfig die Permissions evtl _absichtlich_ anders setzt als im RPM angegeben.
Stimmt.
und fuer den Rest ist 'rpm --verify' dein Freund.
Ich würde eher ein find empfehlen, das nach Dateien sucht, die noch work:users gehören.
Ack. Also wohl rpm --setugids, dann rpm --verify, dann
Falls man das --verify überhaupt laufen lassen will. Nach einem --setugids dürfte es sowieso keine Fehler bei den Berechtigungen finden ;-) Falls es Dir um mögliche Änderungen an Dateien geht: Wäre ich ein Angreifer, würde ich irgendeine Datei in /etc ändern (z. B. profile.local oder so) und nicht irgendwas in /bin/ oder /usr/bin/. Grund: Unterschiede in /bin/ oder /usr/bin/ fallen sofort auf - schließlich sind das Dateien, die sich "nicht ändern dürfen". Änderungen an Dateien in /etc/ sind dagegen nur mühsam nachzuvollziehen, da dort ja auch bewusst geänderte Configfiles rumliegen. Man müsste also alle geänderten Configfiles von Hand durchgehen, was doch einige Zeit in Anspruch nimmt. Und auf den Zeitstempel kann man sich auch nicht verlassen, da ein gewissenhafter Angreifer immer touch mit einem älteren Datum ausführen würde ;-)
SuSEconfig.permissions und dann das find?
Jepp, die Reihenfolge passt. Was noch work:users gehört, muss auf jeden Fall manuell korrigiert werden (außer /home/work/ ;-)
Oder das --verify doch erst nach dem SuSEconfig?
Das verwirrt eher, da ja SuSEconfig.permissions etliche Dateirechte wieder ändert - diese würden dann angemeckert...
Hm. Wie waere mit sowas wie einem (ungetestet dahingetipperten):
find / -user work -group users -print0 \ | xargs -0 rpm -qf 2>/dev/null
Mit 2>/dev/null unterschlägst Du Dateien, die zu keinem Paket gehören - und die können durchaus kritische Daten enthalten (viele Dateien in /etc/sysconfig/ gehören zu keinem Paket...)
| sort -u | while read pkg; do rpm --verify "$pkg" ## oder gleich 'rpm --setugids "$pkg"' done
Siehe oben - wegen user/group braucht man das --verify nicht mehr. Und wenn man auf Dateiänderungen prüfen will, sollte man es _vor_ dem --setugids machen, damit find die relevanten Dateien auch wirklich findet (nach --setugids gehören die ja wieder root o. a. und fallen durchs Suchraster). Alternativ kann man auch gleich rpm --verify -a nehmen - das überprüft in diesem Fall nur unwesentlich mehr Pakete und man kann sicher sein, dass man nichts übersehen hat ;-)
Das was dann noch ueberbleibt sollte sich durch Raten und/oder anhand eventueller Fehlermeldungen korrigieren lassen ("work.users" in /var/lib/rpm/*? Nee, ich glaub nich ;))
*g* Nochmal zusammengefasst - ich würde ich so vorgehen: rpm --setugids -a rpm --verify -a # angemeckerte Dateien manuell nachprüfen SuSEconfig.permissions find / -user work -group users # gefundene Dateien manuell chown'en
Und nochwas: obiges ist wieder mal ein Beispiel, wie maechtig (wenn auch manchmal scheinbar(!) langsam) die "klassische" Unix-Kommandozeile sein kann :)))
ACK!
Man kann aber ja derweil was anderes machen, z.B. in einem anderen xterm/auf einer anderen Konsole mail oder news lesen *bg*
Wie? Mail auf einer Konsole? Du weißt doch, dass ich meine Mails mit der Maus durch die Gegend schubsen will ;-) *flücht*
Aber Achtung: kann sein, dass ich da "GNUisms" wie das 'find -print0 | xargs -0' und evtl. das '-u' beim 'sort' eingebaut habe (bei Letzterem waere stattdessen 'sort | uniq' zu verwenden).
Da wir ja von SuSE Linux reden, dürfte das kein Problem sein ;-)
--
"Der Pinguin ist ein gutes Logo für Linux, denn was nicht fliegt, stürzt auch nicht ab." Francis Kuhlen (IBM-Vice President Sales)
Snarfed! Aber was macht die Leerzeile da?
Die ist mir reingerutscht, weil ich die Sig von Hand gekürzt habe. Im Original ist da ein Männchen dahinter, das den Text auf einem Schild vor sich hält. Nur ist das für eine ML eben ein paar Zeilen zu lang - ich habe es dann manuell weggekürzt und die Leerzeile übersehen ;-) Gruß Christian Boltz --
[Strings in C] Das würde alles nur Aussagen über die glibc erlauben. Aha, die ist Dir nicht autoritativ genug. Jetzt kenne ich endlich Dein eigentliches Problem: Der Papst muss die 0 am Ende absegnen ;-) [> Thorsten Haude und Jan Trippler in suse-linux]