Unsichtbare Dateien, die OS X-Schlüsselbund zugeordnet sind

Nach vielen Nachforschungen habe ich die meisten meiner Fragen beantwortet:

1. Die unsichtbare Datei implementiert eine Schreibsperre für die Schlüsselbunddatenbank.
2. .fl ist das Dateinamenspräfix für Sperrdateien, die von der Klasse AtomicFile im Sicherheitsframework erstellt wurden.
3. Die 8 Hex-Zeichen im Dateinamen sind der Anfang des SHA-1-Hashs des Dateinamens des Schlüsselbunds. Wenn die Schlüsselbunddatei beispielsweise Test.keychain heißt, beginnt der SHA-1-Hash seines Dateinamens mit 1BCE4B9A... und die Sperrdatei heißt daher .fl1BCE4B9A .
4. Ich habe keine Möglichkeit gefunden, zu verhindern, dass die Sperrdatei erstellt wird, wenn ein Schlüsselbund erstellt oder geändert wird. Ich denke, es ist wahrscheinlich unmöglich, aber Ich wäre sehr interessiert, wenn jemand einen Weg finden könnte, es zu tun .

Hier sind die Details meiner Untersuchung:

Schlüsselbund ist gesperrt / entsperrt

Ich habe festgestellt, dass die unsichtbare Datei nicht von gesperrt / unlocked Status. Wenn die unsichtbare Datei gelöscht wurde, macht das Sperren / Entsperren des Schlüsselbunds die nicht sichtbare Datei nicht neu.

Systemaufrufe

Ich habe einige Nachforschungen angestellt, indem ich die File Activity-Vorlage in Apples Instruments Werkzeug.

Diese Systemaufrufe sind verantwortlich für die Manipulation der unsichtbaren Datei:

• Erstellen der unsichtbaren Datei, wenn ein neuer Schlüsselbund erstellt wird:
  • Security::AtomicFile::create(unsigned short)
  • Security::RefPointer<Security::AtomicLockedFile>::release_internal()
  • Relevanter Teil der Anrufstruktur
• Erneutes Erstellen der unsichtbaren Datei, wenn der Inhalt eines Schlüsselbunds geändert wird:
  • Security::AtomicFile::write()
  • Security::RefPointer<Security::AtomicLockedFile>::release_internal()
  • Relevanter Teil der Anrufliste
• Löschen der unsichtbaren Datei, wenn ein Schlüsselbund gelöscht wird:
  • Security::AtomicFile::performDelete()
  • Relevanter Teil der Anrufliste

C ++ Dateien

Dies sind die relevanten Dateien und Klassen (Quellcode aus Apple Open Source für OS X 10.9.2 ):

• AtomicFile.cpp
  • Security::AtomicFile
  • Security::AtomicLockedFile
  • Security::AtomicTempFile
  • Security::LocalFileLocker
• AppleDatabase.cpp
  • Security::AppleDatabase
  • Security::DbModifier

Kommentare im Quelltext

Die Kommentare in diesen Dateien haben einige Hinweise geliefert:

• %Code%
  • "Berechne den Namen der Sperrdatei für diese Datei"
• %Code%
  • "Sperren Sie die Datei zum Schreiben und geben Sie eine neu erstellte AtomicTempFile zurück."
  • "Nachdem wir die Sperre und die neue db-Datei erstellt haben, erstellen Sie ein tempfile-Objekt."
• %Code%
  • "Wenn die Sperrdatei nicht existiert, erstellen Sie sie"
  • "versuchen Sie, exklusiven Zugriff auf die Datei"
  zu erhalten
  • "Überprüfen Sie, ob die Datei, auf die wir Zugriff haben, noch existiert. Wenn nicht, hat eine andere Datei unsere Dateisperre wegen einer Hash-Kollision geteilt und unsere Sperre weggeworfen - oder ein Benutzer hat die Sperrdatei selbst weggeblasen . "
• %Code%
  • "Jetzt halten wir die Schreibsperre"
• %Code%
  • "Sperren Sie die Datenbankdatei zum Schreiben und geben Sie eine neu erstellte AtomicTempFile zurück."
• %Code%
  • "Erwerben Sie die Schreibsperre und entfernen Sie die Datei."
  • "Verknüpfung unserer Sperrdatei aufheben"

Generierung des Namens der Sperrdatei

Ich habe diesen Code im AtomicFile::AtomicFile() -Konstruktor gefunden:

Dabei steht AtomicFile::create() für die ersten 4 Byte des SHA-1 Hash des Dateinamens des Schlüsselbuchs.

Hinweis: Wenn nur 4 Bytes (32 Bits) des Hashs verwendet werden, gibt es ein vernünftige Chance einer Hash-Kollision , die im Kommentar in LocalFileLocker::lock() erwähnt wird.

Operation der Sperre

Der DbModifier::modifyDatabase() Systemaufruf ist verwendet, um die Sperre für die Sperrdatei zu manipulieren.

Hier ist der Aufrufbaum, wenn die Datenbank des Schlüsselbunds zum Schreiben gesperrt ist:

und wenn es nach dem Schreiben entsperrt wird: