W jaki sposób zabezpieczony jest brelok systemowy w systemie OS X?

22

Szukam czegoś takiego jak ta biała księga bezpieczeństwa na iOS z wyjątkiem OS X lub nawet lepszego, jakiegoś rodzaju raportu z audytu bezpieczeństwa od niezależnego eksperta. Po przeczytaniu dokumentacji, takiej jak Przewodnik programowania usług pęku kluczy , jestem jeszcze bardziej zdezorientowany, co jest podatne na atak przeciwny na niezaszyfrowaną kopię zapasową systemu OS X.

Ostatnim razem, gdy sprawdzałem, brelok logowania użytkownika w systemie OS X był tak samo bezpieczny jak hasło. Pamiętam jakiś problem, który skrócił rzeczywistą tajemnicę klucza do czegoś takiego jak 111 bitów (mglista pamięć, proszę o poprawienie mnie) z powodu jakiegoś problemu z konwersją hasła na klucz, ale to było dawno temu i mam nadzieję, że zostało to naprawione.

Z drugiej strony powiedziano mi, że systemowy brelok jest z natury mniej bezpieczny, ponieważ każdy administrator może uzyskać do niego dostęp, a intruz ma wiele opcji zostania administratorem, oprócz odgadywania hasła jednego użytkownika.

W szczególności martwię się o przechowywanie haseł używanych w skryptach automatycznych w pęku kluczy systemowych, ponieważ kopie zapasowe plików systemowych są przechowywane poza witryną bez dalszego szyfrowania. Dokumenty i inne dane użytkownika są szyfrowane przed przeniesieniem ich poza witrynę, ale mam dokuczliwe podejrzenie, że przeoczam ścieżkę, która odzyskuje te klucze po naruszeniu pęku kluczy systemowych (z powodu naszych procedur, niekoniecznie żadnych wad kryptograficznych) . Chcę więc dokładnie zrozumieć, w jaki sposób systemowy pęku kluczy jest jednocześnie zabezpieczony, ale dostępny dla każdego administratora.

  1. W jaki sposób są zbudowane klucze, aby każdy użytkownik administracyjny mógł odblokować pęku kluczy systemu?

  2. Czy istnieją ograniczenia kryptograficzne, które w jakikolwiek sposób ograniczają to, co użytkownik administracyjny może zrobić z informacjami w pęku kluczy systemu?

  3. Biorąc pod uwagę system tworzenia kopii zapasowych niezaszyfrowane bez /Users , w jaki sposób uzyskać dostęp do kluczy w pęku kluczy systemu?

Interesuje mnie OS X 10.5 Leopard i nowsze wersje.

Old Pro
źródło
Nie mam odpowiedzi, ale anegdota: jako standardowy użytkownik bez uprawnień administratora byłem kiedyś w stanie stosunkowo łatwo wyodrębnić hasła z pęku kluczy Systemu. Nie pamiętam dokładnych kroków, ale z pewnością było to możliwe. Na marginesie, czy może być lepiej na security.stackexchange.com ?
alexwlchan
@Alex, najpierw wypróbowałem Security.SE, ale nie otrzymałem tam odpowiedzi.
Old Pro
1
Dlaczego nie użyć osobnego pęku kluczy do tego, co robisz? Czy istnieje dobry powód, dla którego twój skrypt potrzebuje dostępu do pęku kluczy systemu?
Jay Thompson,
@eyemyth, tak, skrypty muszą być uruchamiane przez system, aby mogły uzyskać dostęp do wszystkich plików na dysku, niezależnie od uprawnień użytkownika.
Old Pro

Odpowiedzi:

11

/Library/Keychains/System.keychainBrelok systemowy jest przechowywany, a klucz do odblokowania jest przechowywany w /var/db/SystemKey(domyślne uprawnienia do plików są odczytywane tylko przez root). Lokalizacja tych plików jest podana w skrypcie systemu kontroli bezpieczeństwa (ze źródła security_systemkeychain ). Możliwe jest nawet przetestowanie automatycznego blokowania / odblokowywania pęku kluczy systemowych za pomocą

systemkeychain -vt

Struktura bezpieczeństwa pęku kluczy pozwala programom nieuprzywilejowanym na wysyłanie żądań informacji, pod warunkiem że znajdują się one na liście ACL zapisanej w pozycji pęku kluczy. Oczywiście, jeśli użytkownik ma root w systemie, może bezpośrednio uzyskać dostęp zarówno do pliku przechowującego systemowy brelok, jak i klucz do jego odblokowania, dlatego nie ma żądań za pośrednictwem struktury zabezpieczeń i nie jest przypisany do list ACL przechowywanych w pęku kluczy samo.

(Właściwie nie odpowiedziałem na oryginalne pytania, więc spróbujmy jeszcze raz)

W jaki sposób są zbudowane klucze, aby każdy użytkownik administracyjny mógł odblokować pęku kluczy systemu?

Struktura pęku kluczy libsecurity pozwala regularnym procesom współdziałać z pękiem systemu w sposób uwierzytelniony przy użyciu szkieletu komunikacji międzyprocesowej Apple'a (IPC).

Program A wysyła żądanie dostępu do informacji o pęku kluczy systemu za pomocą IPC. Sprawdzane jest, czy żądający użytkownik jest już w grupie kół, a także zna hasło użytkownika w grupie kół. Po potwierdzeniu autoryzacji uprzywilejowanego kcproxydemona można użyć do uzyskania dostępu do materiału /var/db/SystemKey, odblokowania pęku kluczy systemu i zwrócenia żądanych informacji.

Czy istnieją ograniczenia kryptograficzne, które w jakikolwiek sposób ograniczają to, co użytkownik administracyjny może zrobić z informacjami w pęku kluczy systemu?

Nie - użytkownik administracyjny może uzyskiwać dostęp / zmieniać cokolwiek w pęku kluczy systemu. Nawet jeśli nie mogliby, mogli skopiować pliki bazowe na inny komputer, na którym mają pełną kontrolę, i po prostu odblokować / uzyskać do nich dostęp.

Biorąc pod uwagę niezaszyfrowaną kopię zapasową systemu bez / Users, jak uzyskasz dostęp do kluczy w Systemowym pęku kluczy?

Jeśli kopia zapasowa zawierała kopie, /Library/Keychains/System.keychaina /var/db/SystemKeynastępnie skopiowałbym je do odpowiednich lokalizacji w nowym systemie OS X i użyłem, systemkeychainaby później odblokować ten pierwszy i zrzucić bazę danych pęku kluczy za pomocą security dump-keychain.

Zaraz
źródło
1
Istnieje narzędzie o nazwie dumpkeychain z GuidanceSoftware / EnCase, które pozwala na bezpośrednie zrzut systemowego pęku kluczy (za pomocą SystemKey) w systemie Windows (może być łatwiejsze niż skonfigurowanie nowej instalacji OS X w celu zrzucenia).
drfrogsplat
1
@Anon, jak mogę wykorzystać powyższe informacje do uzyskania dostępu / odblokowania / zrzutu pliku System.keychain z kopii zapasowej Time Machine innego komputera? To znaczy, że mam System.keychain i SystemKey przechowywane na dysku zewnętrznym, więc chyba muszę określić ścieżki do obu plików, aby uniknąć używania plików w domyślnej lokalizacji.
db
Ten post jest powiązany (jak używać SystemKey do odszyfrowywania System.keychain ze starego systemu). apple.stackexchange.com/questions/307189/ ... Jestem ciekawy, czy istnieje sposób z Keychain Access lub systemkeychain cli na odblokowanie odzyskanego klucza System.keych (tj. ze starego uszkodzonego dysku twardego) za pomocą odpowiedniego klucza systemowego z tej samej instalacji. Moim celem jest odblokowanie i migracja danych logowania do nowego pęku kluczy systemu w nowej instalacji.
mattpr
5

Brelok systemowy

Brelok systemowy ma kilka unikalnych możliwości. Są one udokumentowane na stronie podręcznika systemkeychain . Wzmianki o głównym haśle prawdopodobnie będą Twoim celem. Kod źródłowy specyficzny układ keychain jest mały i dostępny.

Systemowy brelok, /System/Library/Keychains/System.keychainto specjalny brelok do użytku dla Apple i demonów. Ogólnie należy unikać używania go do skryptów na poziomie użytkownika.

Przegląd kodu: pęku kluczy

Apple opublikowało kod źródłowy Keychain i ramy bezpieczeństwa dla Mac OS X 10.5; możesz przejrzeć ten kod, aby dowiedzieć się, jak on działa.

Alternatywne podejście: oddzielny pęku kluczy

Możesz utworzyć osobny brelok do przechowywania poświadczeń skryptu. Polecamy tę praktykę naszym klientom. Możesz użyć zabezpieczeń narzędzia wiersza poleceń, aby uzyskać dostęp, wyodrębnić pęki kluczy i zarządzać nimi bez uciekania się do interfejsu graficznego.

Rozważ przechowywanie haseł do automatycznych skryptów w osobnym pęku kluczy - i wyklucz ten pęku kluczy z kopii zapasowej poza witryną.

Doceniam, że usunięcie pęku kluczy z kopii zapasowej nie jest idealne, ale rozwiązałoby to Twoje obawy. Podczas przywracania komputera Mac musisz odzyskać pęku kluczy z innego źródła; może być bardziej zaufanym źródłem lub bocznym kanałem.

Zawsze możesz przechowywać osobne hasło pęku kluczy w pęku kluczy systemu. Następnie możesz odblokować oddzielny pęku kluczy ze skryptu. Jeśli kopia zapasowa zostanie zaatakowana, ujawnisz hasło tylko do osobnego pęku kluczy, a nie do samego pęku kluczy, ponieważ ten plik nie zawiera kopii zapasowej poza witryną.

Graham Miln
źródło
Dzięki, ale zdecydowanie trudniej jest mi zrozumieć z całego tego kodu, w jaki sposób zabezpieczony jest brelok systemowy i co go zabezpiecza. Musimy użyć Systemowego pęku kluczy, ponieważ potrzebujemy, aby skrypty były uruchamiane automatycznie w tle z uprawnieniami administratora, niezależnie od tego, kto jest zalogowany.
Old Pro
1
Zalecam, aby zapytać albo na liście mailingowej Apple CDSA ( lists.apple.com/mailman/listinfo/apple-cdsa ), albo korzystając z pomocy technicznej Apple. Tylko dzięki tym środkom możesz zagwarantować dotarcie do odpowiednich inżynierów Apple.
Graham Miln,
Uruchamianie skryptów w tle podczas uruchamiania roota. Co dokładnie próbujesz zrobić?
Jay Thompson,
1
Niewielka literówka w „/System/Library/Keychains/System.keychain” (Zapomniałeś „Library”). W rzeczywistości możesz uzyskać listę lokalizacji pęku kluczy w Keychain Access, wybierając „Edycja> Lista pęków kluczy”
nazwa użytkownika
1
@OldPro Biorąc pod uwagę obawy związane z bezpieczeństwem, dlaczego nie skorzystać z pełnego szyfrowania dysku?
Graham Miln
2

Firma Apple niedawno opublikowała dokument opisujący swoje praktyki bezpieczeństwa , możesz tam znaleźć odpowiedzi. Dokument jest specyficzny dla iOS, ale wiele funkcji bezpieczeństwa ma wiele wspólnego z OS X.

demianturner
źródło
To jest właściwa ścieżka i dobry przykład dokumentacji, którą uważam za pomocną, ale iOS nie ma pojęcia Systemowego pęku kluczy, więc nie odpowiada na moje pytanie.
Old Pro
Z przyjemnością przyjmuję twoją nagrodę, jeśli to
poprowadzi
0

Nie mam szczegółowej wiedzy na temat pęku kluczy *, ale jest to dość standardowa praktyka.

  1. Chcesz chronić zwykły plik tekstowy „foo”. Foo może mieć dowolną wielkość.
  2. Utwórz klucz symetryczny do szyfrowania foo.
  3. Zaszyfruj klucz symetryczny za pomocą klucza wyodrębnionego z hasła.

Po wykonaniu tej czynności możesz zmienić „hasło”, wprowadzając bieżące hasło, odszyfrowując klucz symetryczny, a następnie szyfrując go nowym hasłem. Pozwala to uniknąć długotrwałych procesów odszyfrowywania / szyfrowania w przypadku, gdy „foo” jest bardzo duże.

Jak to działa dla wielu użytkowników, którzy potrzebują dostępu do zwykłego tekstu foo? Całkiem proste, po prostu tworzysz zaszyfrowaną kopię klucza symetrycznego raz dla każdego użytkownika. Innymi słowy, wykonaj krok trzeci dla każdego użytkownika.

W praktyce wszystko to jest oderwane od widoku, a użytkownik końcowy musi mieć do czynienia tylko z własnym hasłem.

W odniesieniu do części 3 pytań klucze użytkowników nie są przechowywane w ich domu. Najprawdopodobniej byłyby /private/vargdzieś przechowywane . Więc nawet bez /Userskogoś, kto wcześniej miał dostęp, byłby w stanie odblokować system.


* Możliwe, że pęku kluczy działa inaczej.

bahamat
źródło
Tym, co różni się w pęku kluczy systemu, jest to, że system ma dostęp do tego, co jest w pęku kluczy, niezależnie od tego, kto jest zalogowany. Na przykład Time Machine może uzyskać dostęp do pęku kluczy systemu w celu zamontowania zdalnego udziału plików, nawet jeśli zalogowany jedyny użytkownik nie jest użytkownik administracyjny i dlatego nie może uzyskać dostępu do pęku kluczy systemu. Więc dzieje się coś jeszcze i chciałbym wiedzieć dokładnie, co to jest.
Old Pro
Ponownie, mogę tylko przypuszczenie, ale IMO to nie jest faktycznie , że różne. Sam system oczywiście może uzyskać klucz, to prawda. Zakładam, że istnieje klucz systemowy traktowany podobnie jak klucze użytkownika. Ale teraz jesteśmy w centrum twojego pytania… co zapewnia pierwszy dostęp?
bahamat