Rekonstruktion der TSD mit Hilfe von Paket-Metadaten auf dem System

Under Construction

Arbeiten mit AIX -> AIX-Sicherheit > Trusted Execution (TE) > Vor der Aktivierung von Trusted Execution > Sind die Einträge in der TSD korrekt?

Rekonstruktion der TSD mit Hilfe von Paket-Metadaten auf dem System

Nachfolgend soll gezeigt werden, wie auf einem AIX System mit Hilfe von Paket Metadaten die TSD rekonstruiert werden kann. Dies kann unter anderem in folgenden Fällen interessant sein:

- Rekonstruktion der TSD für einen Vergleich mit der aktuell verwendeten TSD.
- Wiederherstellen und/oder Korrigieren von fehlenden Einträgen.

Sinn macht dies jedoch nur, falls sichergestellt ist das die Paket Metadaten unverändert (und vollständig) sind. Wurde ein System kompromitiert, könnten davon auch die Paket-Metadaten betroffen sein.

Auf jedem AIX System werden bei der Installation von installp Paketen/Filesets eine ganze Reihe von Metadaten unter /lpp und /usr/lpp abgelegt. Wird beispielsweise ein Base-Level Fileset installiert, welches Einträge für die TSD enthält, dann sind diese in einer Datei mit dem Namen des Fileset und der Endung „.sec“ (bzw. „.lib.sec“ für Library Einträge) abgespeichert. Die Datei befindet sich im Package-Control-File liblpp.a des root Parts und wird unterhalb von /usr/lpp abgespeichert. Nachfolgend ein Beispiel für das Fileset bos.adt.syscalls (Paket ist bos.adt):

/usr/lpp/bos.adt/inst_root/bos.adt.syscalls.lib.sec
/usr/lpp/bos.adt/inst_root/bos.adt.syscalls.sec

Unterhalb von /usr/lpp gibt es für jedes Paket ein eigenes Unterverzeichnis mit dem Namen des Pakets, hier bos.adt. Darunter gibt es dann für den root Part das Unterverzeichnis inst_root, unterhalb dem dann die Datei(en) mit den TSD-Security-Einträgen zu finden sind. Der Name setzt sich aus dem Namen des Filesets und der Endung „.sec“ bzw. „.lib.sec“ zusammen.

Werden Updates installiert, werden an anderer Stelle für jede installierte Version ebenfalls solche Dateien mit TSD-Einträgen abgespeichert. Hier wieder für das Beispiel bos.adt.syscalls (Version 7.3.2.1):

/usr/lpp/bos.adt/bos.adt.syscalls/7.3.2.1/inst_root/bos.adt.syscalls.lib.sec
/usr/lpp/bos.adt/bos.adt.syscalls/7.3.2.1/inst_root/bos.adt.syscalls.sec

Im Paket-Unterverzeichnis /usr/lpp/bos.adt wird für jedes zugehörige Fileset ein Unterverzeichnis mit dem Fileset-Namen angelegt, hier bos.adt.systcalls, darunter dann ein Verzeichnis mit der Versionsnummer, hier 7.3.2.1. Darunter gibt es für den root Part wieder das Unterverzeichnis inst_root, worunter dann letztlich die Dateien mit den TSD-Einträgen abgelegt sind.

Hinweis: Die beschriebenen Möglichkeiten sind leider nicht alle Möglichkeiten, es gibt weitere die hier nicht beschrieben sind.

Mit Hilfe all dieser Security-Dateien der installierten Base-Level und Update Filesets sollte sich die TSD eines Systems rekonstruieren lassen.

Wird ein AIX System installiert, dann werden zunächst Dateien aus der BFF Datei bos extrahiert, als Grundlage für alles weitere. Dabei wird auch eine initiale Version der TSD extrahiert:

# restore -Tqvf bos | grep tsd.dat
New volume on bos:
Cluster 51200 bytes (100 blocks).
    Volume number 1
    Date of backup: Thu Oct 27 18:24:24 2022
    Files backed up by name
    User BUILD
    files archived: 2602
     1226876 ./usr/lpp/bos/inst_root/etc/security/tsd/tsd.dat
      179269 ./usr/lpp/bos/inst_root/etc/security/tsd/lib/lib.tsd.dat
#

Hinweis: Das sind die initialen Versionen der TSDs für AIX 7300-02-02-2420.

Im Folgenden skizzieren wir das Vorgehen zur Rekonstruktion der TSD. Wir gehen aber dabei nicht auf alle Details ein, da dies den Rahmen an dieser Stelle sprengen würde. Die beschriebenen Schritte, inklusive weiterer Details, haben wir in Form eines Shell-Skripts (tsd_reconstruct) implementiert. Ein Beispiellauf ist weiter unten gezeigt.

Die TSD wird nachfolgend in Form der beiden Dateien my.tsd.dat und my.lib.tsd.dat im aktuellen Verzeichnis rekonstruiert.

Schritt 1:

Um die TSD auf einem AIX System rekonstruieren zu können, benötigt man als erstes die initialen Versionen von /etc/security/tsd/tsd.dat und /etc/security/tsd/lib/lib.tsd.dat. Diese werden standardmäßig bei der Installation zusätzlich unter /usr/lpp/bos/inst_root/etc/security/tsd auf jedem AIX System abgelegt. Wir kopieren diese als my.tsd.dat und my.lib.tsd.dat ins aktuelle Verzeichnis:

# cp /usr/lpp/bos/inst_root/etc/security/tsd/tsd.dat my.tsd.dat
# cp /usr/lpp/bos/inst_root/etc/security/tsd/lib/lib.tsd.dat my.lib.tsd.dat
#

Die beiden initialen TSDs bringen dabei schon einmal etwas mehr als 1000 Einträge mit:

# trustchk -F my.tsd.dat -q ALL | grep ^/ | wc -l
    1375
# trustchk -F my.lib.tsd.dat -q ALL | grep ^/ | wc -l
    244
#

Allerdings sind viele der Einträge nicht mehr korrekt, da sie durch Base-Level und Update Filesets überschrieben werden:

# trustchk -F my.tsd.dat -n ALL
trustchk: /usr/bin/dirname: Verification of attributes failed: hashvalue signature
trustchk: /usr/bin/pr: Verification of attributes failed: hashvalue signature
trustchk: /usr/lib/instl/instal: Verification of attributes failed: size hashvalue signature
trustchk: /usr/bin/ps: Verification of attributes failed: size hashvalue signature
trustchk: /usr/lib/ras/snapscripts/gettrc: Verification of attributes failed: size hashvalue signature
trustchk: /usr/lib/drivers/ldtermkdb: Verification of attributes failed: hashvalue signature
…
#

Hinweis: Der Präfix „my“ soll kenntlich machen, das es sich hier um Dateien handelt, die von uns konstruiert werden.

Schritt 2:

Für alle installierten Filesets müssen dann die TSD-Einträge des installierten Base-Levels wieder hergestellt werden. Wir demonstrieren dies am Beispiel von bos.adt.syscalls. Die gleichen Schritte müssen für alle anderen Filesets ebenfalls ausgeführt werden.

Zunächst überprüfen wir, ob es schon Einträge für bos.adt.syscalls in my.tsd.dat gibt:

# trustchk -F my.tsd.dat -q $(lslpp -fqc bos.adt.syscalls | cut -d: -f3 | grep / | grep -v -- -)
trustchk: Stanza not found: /usr/lib/lowsys.exp
trustchk: Stanza not found: /usr/lib/kdb_cmd.exp
trustchk: Stanza not found: /usr/lib/threads.exp
trustchk: Stanza not found: /usr/lib/netinet.imp
trustchk: Stanza not found: /usr/lib/kdb.exp
trustchk: Stanza not found: /usr/lib/key.imp
trustchk: Stanza not found: /usr/lib/statcmd.exp
trustchk: Stanza not found: /usr/lib/syscalls.imp
trustchk: Stanza not found: /usr/include/sys/libcsys.h
trustchk: Stanza not found: /usr/lib/kernex.imp
trustchk: Stanza not found: /usr/lib/libsys.a
trustchk: Stanza not found: /usr/lib/libcsys.a
trustchk: Stanza not found: /usr/lib/sockets.exp
#

Hinweis: Das letzte grep filtert Einträge für symbolische Links heraus, da es für diese keinen eigenen TSD-Eintrag gibt.

Offensichtlich gibt es noch keine TSD-Einträge für Dateien aus dem Fileset bos.adt.syscalls.

Das Fileset bos.adt.syscalls hat gehört zum Paket bos.adt:

# lslpp -Lqc bos.adt.syscalls
bos.adt:bos.adt.syscalls:7.3.2.1: : :C:F:System Calls Application Development Toolkit: : : : : : :0:0:/:2419
#

Hinweis: Das erste Feld ist der Paket-Name und das zweite Feld das Fileset.

Dementsprechend müsste es unter /usr/lpp/bos.adt/inst_root die Datei bos.adt.syscalls.sec und eventuell die Datei bos.adt.syscalls.lib.sec geben. Diese enthalten die TSD-Einträge für die Base-Level Version von bos.adt.syscalls:

# find /usr/lpp/bos.adt/inst_root -name "bos.adt.syscalls.*sec" -ls
63502   29 -rw-r-----  1 root      system       29116 May  5 11:26 /usr/lpp/bos.adt/inst_root/bos.adt.syscalls.lib.sec
63503    2 -rw-r-----  1 root      system        1825 May  5 11:26 /usr/lpp/bos.adt/inst_root/bos.adt.syscalls.sec
#

Die zu rekonstruierenden TSDs müssen mit diesen Einträgen aktualisiert werden. Dazu kann aber nicht die Option „-u“ (update) von trustchk verwendet werden, da diese keine Änderung der Signatur oder des Hashes erlaubt. Daher muss ein schon vorhandener Eintrag zuerst entfernt werden, um anschließend die neue Version des Eintrags wieder hinzuzufügen. Wir hatten oben schon festgestellt das unsere rekonstruierte TSD noch keine Einträge für bos.adt.syscalls enthält, dementsprechend würde ein hinzufügen ausreichen. Im Allgemeinen gibt es aber in der Regel schon zumindest einige Einträge. Daher empfiehlt es sich erst einmal alle zu aktualisierenden Einträge aus der TSD zu entfernen:

# trustchk -F my.tsd.dat -d -f /usr/lpp/bos.adt/inst_root/bos.adt.syscalls.sec
trustchk: Stanza not found: /usr/lib/libcsys.a
trustchk: Stanza not found: /usr/lib/libsys.a
#

Hinweis: Werden Einträge vom Typ LIB entfernt, werden automatisch alle zugehörigen Einträge aus /etc/security/tsd/lib/lib.tsd.dat entfernt! Auch wenn aus einer eigenen TSD wie my.tsd.dat Einträge entfernt werden.

Jeder nicht gefundene Eintrag führt zu einer Fehlermeldung („Stanza not found“).

Anschließend können die neuen Einträge hinzugefügt werden:

# trustchk -F my.tsd.dat -a -f /usr/lpp/bos.adt/inst_root/bos.adt.syscalls.sec
trustchk: Key file not accessible,Signature calculation failed
trustchk: Key file not accessible,Signature calculation failed
...
trustchk: Key file not accessible,Signature calculation failed
trustchk: Error while processing TSD
trustchk: Error writing to database file
#

Hinweis: Bei Einträgen vom Typ LIB wird versucht die Signatur der im Library Archiv enthaltenen Shared Objekte zu ermitteln, was aber ohne Private-Key File nicht möglich ist.

Trotz der Fehlermeldungen sind die Einträge in unsere TSD übernommen worden, wie eine Überprüfung zeigt:

# trustchk -F my.tsd.dat -q $(lslpp -fqc bos.adt.syscalls | cut -d: -f3 | grep / | grep -v -- -)
trustchk: Stanza not found: /usr/lib/lowsys.exp
trustchk: Stanza not found: /usr/lib/kdb_cmd.exp
trustchk: Stanza not found: /usr/lib/threads.exp
trustchk: Stanza not found: /usr/lib/netinet.imp
trustchk: Stanza not found: /usr/lib/kdb.exp
trustchk: Stanza not found: /usr/lib/key.imp
trustchk: Stanza not found: /usr/lib/statcmd.exp
trustchk: Stanza not found: /usr/lib/syscalls.imp
trustchk: Stanza not found: /usr/include/sys/libcsys.h
trustchk: Stanza not found: /usr/lib/kernex.imp
/usr/lib/libsys.a:
        owner = bin
        group = bin
        mode = 444
        type = LIB
        hardlinks =
        symlinks =
        size = 14487
        cert_tag = 49424d4149583a30344232302d30334233303a324b3a41
        signature = 08fcfff07cabd25d317bf4d30a7f32438ee807a361955d1ae48d1c727366c206308aefaf1f781dd1d1c6a6dc2dacc38308062d5629b6c5ea7cb16698f2187a91378f5fe547fa7e8ae69bea5d30e2c46ed17d574d3fcf39235c21ef683e35436c5f8b614c16e2c702c971da131ebf53b44e5b04237e2822576b5cb45ec3b9f8110cfeb7584cf76d1d9266297f92d423dbfa9d4740032f4309e135f0cbc60b7bb2024e6ba34cc63d4a58ac7a622917e8bbaa6c734101080eb9b1f9c7f5dbf1bc78fc612458fde752fccaa8abd5ee42262106462374285dd1c9c9c97955701154f08e568aea7d539889b816e35d8cfe408cadae1dc4b2f19daaab3e8ec043d00085
        hash_value = 4eaf8ea3b034d574a534c71f27e2bbe7b6c6ffb7adc4b565ebcbf5c2332616e2
        accessauths =
        innateprivs =
        inheritprivs =
        authprivs =
        secflags =

/usr/lib/libcsys.a:
        owner = bin
        group = bin
        mode = 444
        type = LIB
        hardlinks =
        symlinks =
        size = 42880
        cert_tag = 49424d4149583a30344232302d30334233303a324b3a41
        signature = 0d3aeaebda2c37379384b2849d85c11a40be493952417006e36a11a1485ce2713fd4c818789310f2d76142236c08aac4d9290019a3a5f9ae375edd618ef52b3e8b214aa278c44dca46ec1d08f35cd3e5c5d8558238bef8cac5c721bef9af0e0a6e396aad3cf898d750efd12220c437c86e0b5c75353983ecde7a599f67c314a28918f6e80d0d02248c4ef784f34f5967d96fb8907454d4598dfcb0fd70b924b03c20812e983cdc996063257a6a7d4a403d3506117a09a3f388e7a4ebb0d0703245f383173e2cd3c8a5a57b5adba49df1d8519ea9f439ca903de6c51da902afc16469f174c96b3ffd84ef413a31cac8e3754d67ee4da35a9b0dfd2da889881516
        hash_value = 3eefa9247e8d8288eac4923239eb14b1402f300bbdb4c2dca735602bfb9da91a
        accessauths =
        innateprivs =
        inheritprivs =
        authprivs =
        secflags =

trustchk: Stanza not found: /usr/lib/sockets.exp
#

Eine Überprüfung der neuen Einträge gegen die installierten Dateien ergibt aber noch Abweichungen:

# trustchk -F my.tsd.dat -n $(lslpp -fqc bos.adt.syscalls | cut -d: -f3 | grep / | grep -v -- -)
trustchk: Stanza not found: /usr/lib/lowsys.exp
trustchk: Stanza not found: /usr/lib/kdb_cmd.exp
trustchk: Stanza not found: /usr/lib/threads.exp
trustchk: Stanza not found: /usr/lib/netinet.imp
trustchk: Stanza not found: /usr/lib/kdb.exp
trustchk: Stanza not found: /usr/lib/key.imp
trustchk: Stanza not found: /usr/lib/statcmd.exp
trustchk: Stanza not found: /usr/lib/syscalls.imp
trustchk: Stanza not found: /usr/include/sys/libcsys.h
trustchk: Stanza not found: /usr/lib/kernex.imp
trustchk: /usr/lib/libsys.a: Verification of attributes failed: hashvalue signature
trustchk: /usr/lib/libcsys.a: Verification of attributes failed: size hashvalue signature
trustchk: Stanza not found: /usr/lib/sockets.exp
#

Dies liegt daran das Updates von bos.adt.syscalls installiert wurden. Mit diesen beschäftigen wir uns an etwas späterer Stelle.

Die Einträge zu den Shared Objekten aus bos.adt.syscalls.lib.sec aktualisieren wir in gleicher Weise, indem wir auch hier zunächst die alten Einträge entfernen und dann die neuen Einträge hinzufügen:

# trustchk -F my.lib.tsd.dat -d -f /usr/lpp/bos.adt/inst_root/bos.adt.syscalls.lib.sec
trustchk: Stanza not found: /usr/lib/libcsys.a/64/NCisshift_tmp_64.o
trustchk: Stanza not found: /usr/lib/libcsys.a/64/a64l_64.o
trustchk: Stanza not found: /usr/lib/libcsys.a/64/atoi_64.o
trustchk: Stanza not found: /usr/lib/libcsys.a/64/atoi_table_64.o
...
trustchk: Stanza not found: /usr/lib/libsys.a/64/timeout_64.o
trustchk: Stanza not found: /usr/lib/libsys.a/64/unicount_64.o
# trustchk -F my.lib.tsd.dat -a -f /usr/lpp/bos.adt/inst_root/bos.adt.syscalls.lib.sec
#

Hinweis: Auch hier deuten die Meldungen „Stanza not found“ daraufhin, das es den entsprechenden Eintrag noch nicht gab.

Damit sind die TSD-Einträge für den Base-Level von bos.adt.syscalls schon einmal rekonstruiert in my.tsd.dat und my.lib.tsd.dat.

Schritt 3:

Als nächstes müssen alle Aktualisierungen von TSD-Einträgen über Updates berücksichtigt werden. Auch hier bleiben wir beim Beispiel bos.adt.syscalls. Wir stellen zunächst einmal fest welche Updates des Filesets installiert wurden:

# lslpp -hqc bos.adt.syscalls
/usr/lib/objrepos:bos.adt.syscalls:7.3.1.0::COMMIT:COMPLETE:02/17/25:14;51;07
/usr/lib/objrepos:bos.adt.syscalls:7.3.2.1::COMMIT:COMPLETE:02/17/25:15;04;33
/etc/objrepos:bos.adt.syscalls:7.3.1.0::COMMIT:COMPLETE:02/17/25:14;51;08
/etc/objrepos:bos.adt.syscalls:7.3.2.1::COMMIT:COMPLETE:02/17/25:15;04;33
#

Neben dem Base-Level 7.3.1.0 wurde offensichtlich ein Update auf die Version 7.3.2.1 durchgeführt. In vielen Fällen wird es mehr als einen installierten Update geben. Das nachfolgende Vorgehen muss dann für jede dieser Versionen durchgeführt werden, beginnend bei der niedrigsten Version, bis zur höchsten installierten Version.

Für Updates (konkret Version 7.3.2.1) sollten die Dateien mit den TSD-Einträgen unter /usr/lpp/bos.adt/bos.adt.syscalls/7.3.2.1/inst_root stehen. Die Namen sind wieder bos.adt.syscalls.sec und bos.adt.syscalls.lib.sec:

# find /usr/lpp/bos.adt/bos.adt.syscalls -name "bos.adt.syscalls.*sec"
/usr/lpp/bos.adt/bos.adt.syscalls/7.3.2.1/inst_root/bos.adt.syscalls.lib.sec
/usr/lpp/bos.adt/bos.adt.syscalls/7.3.2.1/inst_root/bos.adt.syscalls.sec
#

Die Vorgehensweise ist wieder die gleiche. Zuerst werden die alten Einträge entfernt, danach werden die neuen Einträge hinzugefügt. Wir führen dies zunächst für my.tsd.dat durch:

# trustchk -F my.tsd.dat -d -f /usr/lpp/bos.adt/bos.adt.syscalls/7.3.2.1/inst_root/bos.adt.syscalls.sec
# trustchk -F my.tsd.dat -a -f /usr/lpp/bos.adt/bos.adt.syscalls/7.3.2.1/inst_root/bos.adt.syscalls.sec
trustchk: Key file not accessible,Signature calculation failed
trustchk: Key file not accessible,Signature calculation failed
trustchk: Key file not accessible,Signature calculation failed
...
trustchk: Key file not accessible,Signature calculation failed
trustchk: Error while processing TSD
trustchk: Error writing to database file
#

Eine Überprüfung unserer aktualisierten TSD gegen die zum Fileset bos.adt.syscalls gehörenden Dateien ergibt leider weiterhin eine Abweichung:

# trustchk -F my.tsd.dat -n $(lslpp -fqc bos.adt.syscalls | cut -d: -f3 | grep / | grep -v -- -)
trustchk: Stanza not found: /usr/lib/lowsys.exp
trustchk: Stanza not found: /usr/lib/kdb_cmd.exp
trustchk: Stanza not found: /usr/lib/threads.exp
trustchk: Stanza not found: /usr/lib/netinet.imp
trustchk: Stanza not found: /usr/lib/kdb.exp
trustchk: Stanza not found: /usr/lib/key.imp
trustchk: Stanza not found: /usr/lib/statcmd.exp
trustchk: Stanza not found: /usr/lib/syscalls.imp
trustchk: Stanza not found: /usr/include/sys/libcsys.h
trustchk: Stanza not found: /usr/lib/kernex.imp
trustchk: /usr/lib/libsys.a: Verification of attributes failed: hashvalue
trustchk: /usr/lib/libcsys.a: Verification of attributes failed: hashvalue
trustchk: Stanza not found: /usr/lib/sockets.exp
#

Bei der Betrachtung des Base-Level Filesets gab es eine Abweichung bei hashvalue und signature. Dieses Mal gibt es „nur“ eine Abweichung bzgl. des Hashes. Wir schauen uns eine der beiden Libraries genauer an:

# trustchk -F my.tsd.dat -q /usr/lib/libsys.a                            
/usr/lib/libsys.a:
        owner = bin
        group = bin
        mode = 444
        type = LIB
        hardlinks =
        symlinks =
        size = 14487
        cert_tag =
        signature = VOLATILE
        hash_value = 13435e8700d69cd241d20c0187c044420a8a583b2acfa7766167d8cc6fe7ace0
        accessauths =
        innateprivs =
        inheritprivs =
        authprivs =
        secflags =

#

Es gibt keine digitale Signatur mehr! IBM gibt bei Updates von Libraries in vielen Fällen keine Signatur mehr an, sondern nur noch einen Hash-Wert (der aber leider in der Regel auch nicht korrekt ist). Der Grund ist letztlich das bei einem Update häufig nur einzelne Shared Objekte in einer Library ausgetauscht werden. Dabei kann die Reihenfolge der Objekte im Archiv von System zu System variieren, je nachdem welche Updates genau installiert wurden. Die konkrete Reihenfolge der Objekte auf einem gegebenen System ist vorab nicht bekannt. Daher kann auch keine Signatur angegeben werden und daher stimmt auch der Hash-Wert in der Regel nicht.

Der Hash-Wert kann z.B. mit Hilfe von openssl ermittelt werden:

# openssl dgst -sha256 /usr/lib/libsys.a
SHA2-256(/usr/lib/libsys.a)= 7fd821ed0b4dc7587e9ec659a85825237792ba7d7a3b099427bb9821b483c381
#

Dieser weicht ganz offensichtlich von dem Hash-Wert aus unserer TSD (my.tsd.dat) ab.

Es gibt mindestens die folgenden drei Möglichkeiten mit diesem Problem umzugehen:

- Den inkorrekten Hash-Wert in der generierten TSD (my.tsd.dat) unverändert stehen lassen. Über Aktionen kann dann später entschieden werden.
- Unter der Annahme das die Library nicht kompromitiert wurde, könnte man den mit openssl ermittelten Hash-Wert in die TSD (my.tsd.dat) übernehmen. Damit gibt es keine Abweichung mehr.
- Unter der Annahme das alle enthaltenen Shared Objekte eine korrekte Signatur haben, könnte man die Library selbst neu erzeugen und von dieser dann den Hash-Wert übernehmen. (Vermutlich die beste Lösung.)

Wir zeigen hier die zweite Variante. Dazu extrahieren wir zunächst den Eintrag für /usr/lib/libsys.a aus unserer TSD (my.tsd.dat) und ersetzen den Hash-Wert durch den durch uns ermittelten Hash-Wert. Das Resultat speichern wir in der Datei libsys.sec im aktuellen Verzeichnis:

# trustchk -F my.tsd.dat -q /usr/lib/libsys.a | \
  sed -e s/13435e8700d69cd241d20c0187c044420a8a583b2acfa7766167d8cc6fe7ace0/7fd821ed0b4dc7587e9ec659a85825237792ba7d7a3b099427bb9821b483c381/ >libsys.sec
#

Anschließend entfernen wir den Eintrag und fügen dann den aktualisierten Eintrag wieder hinzu:

# trustchk -F my.tsd.dat -d -f libsys.sec
# trustchk -F my.tsd.dat -a -f libsys.sec
trustchk: Key file not accessible,Signature calculation failed
trustchk: Key file not accessible,Signature calculation failed
trustchk: Key file not accessible,Signature calculation failed
trustchk: Key file not accessible,Signature calculation failed
trustchk: Key file not accessible,Signature calculation failed
trustchk: Key file not accessible,Signature calculation failed
trustchk: Key file not accessible,Signature calculation failed
trustchk: Error writing to database file
#

Eine erneute Überprüfung zeigt das der Eintrag jetzt mit der installierten Datei /usr/lib/libsys.a übereinstimmt:

# trustchk -F my.tsd.dat -n /usr/lib/libsys.a                            
#

Hinweis: Wir haben die zweite Datei /usr/lib/libcsys.a auf die gleiche Weise aktualisiert.

Die Einträge für Shared Objekte aktualisieren wir auf die gleiche Art wie bei den Base-Level Filesets: alte Einträge wegnehmen und dann die neuen Einträge hinzufügen.

# trustchk -F my.lib.tsd.dat -d -f /usr/lpp/bos.adt/bos.adt.syscalls/7.3.2.1/inst_root/bos.adt.syscalls.lib.sec
# trustchk -F my.lib.tsd.dat -a -f /usr/lpp/bos.adt/bos.adt.syscalls/7.3.2.1/inst_root/bos.adt.syscalls.lib.sec
#

Für weitere Versionen des Filesets muss dieses Vorgehen wiederholt werden.

Damit sollten die TSD Einträge für das Fileset bos.adt.syscalls auf dem aktuellen Stand sein!

Die oben beschriebenen Schritte haben wir in dem Skript tsd_reconstruct implementiert. Im einfachsten Falle rekonstruiert das Skript die komplette TSD (tsd.dat und lib.tsd.dat) eines Systems. Die rekonstruierten Dateien haben per Default die Namen tsd.dat und lib.tsd.dat im aktuellen Verzeichnis, können aber auch über Optionen angegeben werden.

Hier ein Lauf des Skripts mit der Option „-u“ (unsafe):

# tsd_reconstruct -u
Fileset: GSKit8.gskcrypt32.ppc.rte
Fileset: GSKit8.gskcrypt64.ppc.rte
Fileset: GSKit8.gskssl32.ppc.rte
Fileset: GSKit8.gskssl64.ppc.rte
Fileset: ICU4C.rte
…
Fileset: bos.64bit
Fileset: bos.acct
Fileset: bos.adt.base
Fileset: bos.adt.debug
Fileset: bos.adt.include
Fileset: bos.adt.insttools
Fileset: bos.adt.lib
Fileset: bos.adt.libm
Fileset: bos.adt.syscalls
…
#

Hinweis: Mit der Option „-u“ werden Hash-Werte für Libraries vom Skript ermittelt, wie oben demonstriert.

Das Skript hat ca 15 Minuten für die Rekonstruktion der TSD Dateien benötigt. Wir ermitteln kurz die Anzahl der Einträge in den beiden Dateien:

# trustchk -F tsd.dat -q ALL | grep ^/ | wc -l
    8294
# trustchk -F lib.tsd.dat -q ALL | grep ^/ | wc -l
    2511
#

Als nächstes führen wir kurz eine Überprüfung des Systems mit der rekonstruierten TSD aus:

# trustchk -F tsd.dat -n ALL                 
trustchk: /usr/lib/libssl.a: Verification of attributes failed: size hashvalue signature
trustchk: /usr/lpp/bos.sysmgt/nim/methods/c_switch_master: Verification of attributes failed: size hashvalue signature
trustchk: /usr/sbin/niminit: Verification of attributes failed: size hashvalue signature
trustchk: /usr/ccs/lib/libptools_ptr.a: Verification of attributes failed: hashvalue signature
trustchk: /usr/lib/libcrypto.a.min: Verification of attributes failed: size hashvalue signature
trustchk: /usr/lpp/bosinst/bi_main: Verification of attributes failed: size hashvalue signature
trustchk: /usr/sbin/nimclient: Verification of attributes failed: size hashvalue signature
trustchk: /usr/lib/libcrypto.a: Verification of attributes failed: size hashvalue signature
trustchk: /usr/ccs/lib/libdbx.a: Verification of attributes failed: size hashvalue signature
#

Einige der Abweichungen sind auf installierte Ifixes zurück zuführen, die bei der Rekonstruktion nicht berücksichtigt werden. Für Ifixes gibt es keine auf dem System hinterlegten Daten für die TSD-Einträge. Für andere Abweichungen wären die folgenden Möglichkeiten als Ursache denkbar:

- Fehler bei der Rekonstruktion (Skript-Fehler).
- Fehlende Dateien in den Verzeichnissen für die Paket-Metadaten. Fehlen die zugrunde liegenden Dateien mit den TSD-Einträgen, können diese natürlich auch nicht korrekt wieder hergestellt werden.
- Abweichungen aufgrund installierter Ifixes.
- Änderungen durch den Administrator an Dateien, womit diese von den TSD-Einträgen abweichen.
- Änderungen an Dateien durch Angreifer.

Abweichungen sollten natürlich umgehend untersucht werden.

Das Skript tsd_reconstruct unterstützt auch die Wiederherstellung von Einträgen für anzugebende Filesets:

# tsd_reconstruct -v bos.adt.debug
Fileset: bos.adt.debug
delete entries from /usr/lpp/bos.adt/inst_root/bos.adt.debug.sec
add entries from /usr/lpp/bos.adt/inst_root/bos.adt.debug.sec
delete entries from /usr/lpp/bos.adt/inst_root/bos.adt.debug.lib.sec
add entries from /usr/lpp/bos.adt/inst_root/bos.adt.debug.lib.sec
delete entries from /usr/lpp/bos.adt/bos.adt.debug/7.3.2.0/inst_root/bos.adt.debug.sec
add entries from /usr/lpp/bos.adt/bos.adt.debug/7.3.2.0/inst_root/bos.adt.debug.sec
delete entries from /usr/lpp/bos.adt/bos.adt.debug/7.3.2.0/inst_root/bos.adt.debug.lib.sec
add entries from /usr/lpp/bos.adt/bos.adt.debug/7.3.2.0/inst_root/bos.adt.debug.lib.sec
#

Hinweis: Die Option „-v“ steht für verbose und generiert zusätzliche Meldungen zu den Dateien welche TSD-Einträge für die Rekonstruktion enthalten.