Jaka jest tak naprawdę funkcja „rootless” w El Capitan?

Właśnie dowiedziałem się o funkcji „Rootless” w El Capitan i słyszę takie rzeczy, jak „Nie ma użytkownika root”, „Nic nie można zmodyfikować /System” i „Świat się skończy, ponieważ nie możemy się rootować”.

Jaka jest funkcja „Rootless” El Capitan na poziomie technicznym? Co to właściwie oznacza dla wygody użytkownika i doświadczenia programisty? sudo -sNadal będzie działać, a jeśli tak, to jak zmieni się doświadczenie używania powłoki jako rootzmiany?

Po pierwsze: nazwa „rootless” jest myląca, ponieważ nadal istnieje konto root i można uzyskać do niego dostęp (oficjalna nazwa „System Integrity Protection” jest bardziej dokładna). To, co tak naprawdę robi, to ogranicza moc konta root, więc nawet jeśli zostaniesz rootem, nie będziesz mieć pełnej kontroli nad systemem. Zasadniczo chodzi o to, że złośliwe oprogramowanie ma zbyt łatwy dostęp do roota (np. Poprzez wyświetlenie użytkownikowi okna dialogowego uwierzytelniania, które spowoduje odruchowe wprowadzenie hasła administratora). SIP dodaje kolejną warstwę ochrony, której złośliwe oprogramowanie nie może przeniknąć, nawet jeśli zostanie zrootowane. Zła część tego, oczywiście, to, że musi to dotyczyć także rzeczy, które robisz celowo. Ale ograniczenia, które nakłada na root, nie są takie złe; nie zapobiegają większości „normalnym”

Oto, co ogranicza, nawet z katalogu głównego:

• Nie można zmodyfikować coś w /System, /bin, /sbin, lub /usr(z wyjątkiem /usr/local); lub dowolne z wbudowanych aplikacji i narzędzi. Tylko instalator i aktualizacja oprogramowania mogą modyfikować te obszary, a nawet robią to tylko podczas instalowania pakietów podpisanych przez Apple. Ale ponieważ normalne dostosowania w stylu OS X wchodzą /Library(lub ~/Library, lub /Applications), a dostosowania w stylu uniksowym (np. Homebrew) wchodzą /usr/local(lub czasem /etclub /opt), nie powinno to być wielkim problemem. Zapobiega także zapisom na poziomie bloku na dysku startowym, więc nie można tego pominąć.

  Pełna lista zastrzeżonych katalogów (oraz wyjątków takich jak /usr/locali kilka innych) znajduje się w /System/Library/Sandbox/rootless.conf. Oczywiście ten plik jest sam w ograniczonym obszarze.

  Po uaktualnieniu do El Capitan przenosi wszelkie „nieautoryzowane” pliki z obszarów zastrzeżonych do /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• Nie można dołączać do procesów systemowych (np. Działających z tych lokalizacji systemowych) w celu debugowania (lub zmiany ładowanych bibliotek dynamicznych lub niektórych innych rzeczy). Znów niezbyt wielka sprawa; programiści mogą nadal debugować własne programy.

  To blokuje niektóre znaczące rzeczy, takie jak wstrzykiwanie kodu do wbudowanych aplikacji Apple (w szczególności Findera). Oznacza to również, że dtracenarzędzia do monitorowania systemu (np. opensnoop) Nie będą w stanie monitorować i raportować wielu procesów systemowych.

• Nie można ładować rozszerzeń jądra (tekstów), chyba że są one odpowiednio podpisane (tj. Przez Apple lub zatwierdzonego przez Apple programistę). Zauważ, że to zastępuje stary system wymuszania podpisywania kext (i stare sposoby na obejście go). Ale od wersji 10.10.4 Apple ma możliwość włączenia obsługi przycinania dla dysków SSD innych firm , zniknął pierwszy powód używania niepodpisanych kextów.

• Począwszy od Sierra (10.12), niektóre uruchomione ustawienia konfiguracji nie mogą zostać zmienione (na przykład niektórych demonów uruchamiania nie można rozładować).

• Począwszy od Mojave (10.14), dostęp do danych osobowych użytkowników (e-mail, kontakty itp.) Jest ograniczony do aplikacji, które użytkownik zatwierdził, aby uzyskać dostęp do tych informacji. Jest to ogólnie uważane za osobną funkcję (zwaną ochroną danych osobowych lub TCC), ale jest oparte na SIP i wyłączenie SIP również ją wyłącza. Zobacz: „Co i jak macOS Mojave implementuje, aby ograniczyć dostęp aplikacji do danych osobowych?”

Jeśli nie chcesz tych ograniczeń - albo dlatego, że chcesz zmodyfikować swój system ponad to, na co pozwala, lub ponieważ opracowujesz i debugujesz coś takiego, jak kext, który nie jest praktyczny przy tych ograniczeniach, możesz wyłączyć SIP. Obecnie wymaga to ponownego uruchomienia w trybie odzyskiwania i uruchomienia polecenia csrutil disable(podobnie można je ponownie włączyć za pomocą csrutil enable).

Możesz także selektywnie wyłączyć części SIP. Na przykład csrutil enable --without kextwyłączy ograniczenie rozszerzenia jądra SIP, ale pozostawi inne zabezpieczenia.

Ale proszę zatrzymać się i pomyśleć przed wyłączeniem SIP, nawet tymczasowo lub częściowo: czy naprawdę musisz go wyłączyć, czy jest lepszy (zgodny z SIP) sposób na zrobienie tego, co chcesz? Czy naprawdę trzeba zmodyfikować coś /System/Librarylub /binczy coś, albo może iść w lepszym miejscu jak /Libraryi /usr/local/binetc? SIP może „czuć” ograniczenie, jeśli nie jesteś do niego przyzwyczajony, i istnieją uzasadnione powody, aby go wyłączyć, ale wiele z tego, co wymusza, to tak naprawdę najlepsza praktyka.

Aby podkreślić, jak ważne jest pozostawienie jak największej ilości czasu SIP na jak najwięcej czasu, rozważ wydarzenia z 23 września 2019 r. Google wydało aktualizację Chrome, która próbowała zastąpić symboliczny link z /varna /private/var. W większości systemów SIP blokował to i nie było żadnych złych efektów. W systemach z wyłączonym protokołem SIP system macOS był uszkodzony i nie można go uruchomić. Najczęstszym powodem wyłączania SIP było ładowanie niezatwierdzonych (/ nieprawidłowo podpisanych) rozszerzeń jądra (w szczególności sterowników wideo); gdyby tylko wyłączyli ograniczenie kext, nie miałoby to wpływu. Zobacz oficjalny wątek pomocy Google , pytania i odpowiedzi superużytkownika oraz artykuł Ars Technica .

Odniesienia i dodatkowe informacje: prezentacja WWDC na temat „Bezpieczeństwo i Twoje aplikacje” , dobre wyjaśnienie Eldada Eilama na quora.com , przegląd El Capitan w Ars Technica oraz artykuł wsparcia Apple na temat SIP oraz głębokie zanurzenie Richa Troutona ( który również opublikował odpowiedź na to pytanie ).

Dla mnie oznacza to, że DTrace nie działa.

DTrace jest podobny do ptrace / strace w Linuksie, ponieważ pozwala zobaczyć, co proces mówi do jądra. Za każdym razem, gdy proces chce otworzyć plik, napisać plik lub otworzyć port itp., Musi zapytać jądro. W Linuksie ten proces monitorowania odbywa się poza jądrem w „przestrzeni użytkownika”, a zatem uprawnienia są bardzo szczegółowe. Użytkownik może monitorować własne aplikacje (aby naprawić błędy, znaleźć wycieki pamięci itp.), Ale musiałby być rootem, aby monitorować proces innego użytkownika.

DTrace na OSX działa jednak na poziomie jądra, dzięki czemu jest znacznie wydajniejszy i potężniejszy, jednak wymaga dostępu do katalogu głównego, aby dodać swoje sondy do jądra i tym samym zrobić cokolwiek. Użytkownik nie może śledzić własnych procesów bez rootowania, ale jako root może nie tylko obserwować własne procesy, ale w rzeczywistości WSZYSTKIE procesy w systemie jednocześnie. Na przykład możesz obejrzeć plik (za pomocą iosnoop) i zobaczyć, który proces go odczytuje. Jest to jedna z najbardziej użytecznych funkcji wykrywania złośliwego oprogramowania. Ponieważ jądro obsługuje również sieciowe operacje we / wy, to samo dotyczy tam. Wireshark wykrywa nietypową aktywność sieci, DTrace informuje proces wysyłania danych, nawet jeśli są one tak wbudowane w system jak samo jądro.

Jednak w przypadku El Capitan Apple celowo uniemożliwiał działanie DTrace - ponieważ został specjalnie ukierunkowany i wyróżniony jako coś, co ogranicza SIP. Dlaczego mieliby to zrobić? Cóż, wcześniej Apple zmodyfikowało swoje jądro i DTrace, aby umożliwić niektórym procesom rezygnację z monitorowania za pomocą DTrace (co denerwowało wielu badaczy bezpieczeństwa w tym czasie, ponieważ niektóre procesy były obecnie niedostępne, nawet jako root - zawierają złośliwe oprogramowanie). Powodem tego była ochrona DRM w aplikacjach takich jak iTunes, ponieważ teoretycznie ktoś może DTrace i pobierać dane nie-DRM z pamięci procesów.

Istniało jednak ważne obejście, które pozwoliło badaczom nadal wykonywać swoje zadania, a było to zmodyfikować jądro, aby zignorować tę flagę rezygnacji, aby DTrace mógł nadal być wykorzystywany w tych procesach. To było naprawdę świetne, ponieważ programy próbujące uniknąć wykrycia zostały podświetlone za pomocą tej flagi bez DTrace. Wszystko, co Apple lub źli chcieli ukryć, było teraz na widoku ...

Ale to teraz nie działa, więc jak to na ciebie wpływa? Wpłynie to na ciebie zarówno bezpośrednio, jak i pośrednio. Bezpośrednio ograniczy to możliwość monitorowania systemu. Duża liczba niskopoziomowych narzędzi do administrowania i monitorowania systemu (na których opierają się narzędzia wyższego poziomu) przestanie działać. Pośredni efekt będzie jednak znacznie większy - specjaliści ds. Bezpieczeństwa polegają na głębokim dostępie do systemu, aby wykryć najgorsze rodzaje zagrożeń. Po prostu nie możemy tego dłużej robić. Podczas analizowania złośliwego oprogramowania bardzo ważne jest, aby nie wiedział, że działa w debuggerze lub honeypot. Wyłączenie SIP informuje całe oprogramowanie, zarówno złych facetów, jak i Apple, że ten system jest obserwowany. Nigdy więcej oglądania obserwatorów. Jeśli SIP dotyczył bezpieczeństwa, mogliby pouczyć użytkowników o rootowaniu - zamiast tego go usunęli. W ostatecznym rozrachunku oznacza to, że Apple zastąpiło barierę bezpieczeństwa hasła „root all” i „all all”, mechanizmem ochrony SIP „be all and end all”. Lub jeśli jesteś dobry w inżynierii społecznej, hasło roota po ponownym uruchomieniu ...

Jest też to:

System Integrity Protection (SIP) to ogólna polityka bezpieczeństwa, której celem jest zapobieganie modyfikowaniu plików i procesów systemowych przez osoby trzecie. Aby to osiągnąć, ma następujące pojęcia:

• Ochrona systemu plików
• Ochrona rozszerzenia jądra
• Ochrona środowiska wykonawczego

Ochrona systemu plików

SIP uniemożliwia stronom innym niż Apple dodawanie, usuwanie lub modyfikowanie katalogów i plików przechowywanych w niektórych katalogach:

/bin
/sbin
/usr
/System

Apple zaznaczył, że programiści mają dostęp do następujących katalogów:

/usr/local
/Applications
/Library
~/Library

Wszystkie katalogi z /usrwyjątkiem /usr/localsą chronione przez SIP.

Pliki i katalogi chronione SIP można dodawać, usuwać lub zmieniać za pomocą pakietu instalacyjnego podpisanego przez własny urząd certyfikacji Apple. Umożliwia to Apple wprowadzanie zmian w częściach systemu operacyjnego chronionych przez SIP bez konieczności zmiany istniejących zabezpieczeń SIP.

Dane urzędy certyfikacji są zastrzeżone przez Apple na ich własny użytek; Pakiety instalacyjne podpisane identyfikatorem programisty nie mogą zmieniać plików ani katalogów chronionych protokołem SIP.

Aby określić, które katalogi są chronione, Apple zdefiniował obecnie dwa pliki konfiguracyjne w systemie plików. Podstawowy znajduje się w poniższej lokalizacji:

/System/Library/Sandbox/rootless.conf

gdzie rootless.confzawiera listę wszystkich aplikacji i katalogów najwyższego poziomu, które SIP chroni.

Aplikacje

SIP chroni podstawowe aplikacje, które OS X instaluje w aplikacjach i aplikacjach. Oznacza to, że nie będzie już możliwe usuwanie aplikacji instalowanych przez system OS X, nawet z wiersza poleceń podczas korzystania z uprawnień administratora.

Katalogi

SIP chroni również wiele katalogów i dowiązań symbolicznych poza nimi, /Applicationsa najwyższy poziom tych katalogów jest również wymieniony w rootless.conf.

Oprócz zabezpieczeń, Apple zdefiniował również wyjątki od ochrony SIP w pliku rootless.conf, a wyjątki te są oznaczone gwiazdkami. Te wyjątki od ochrony SIP oznaczają, że można dodawać, usuwać lub zmieniać pliki i katalogi w tych lokalizacjach.

Wśród tych wyjątków są:

• /System/Library/User Template - gdzie OS X przechowuje katalogi szablonów, których używa podczas tworzenia folderów domowych dla nowych kont.
• /usr/libexec/cups - gdzie OS X przechowuje informacje o konfiguracji drukarki

Apple uważa ten plik za swój i wszelkie zmiany w nim wprowadzone przez osoby trzecie zostaną zastąpione przez Apple.

Aby zobaczyć, które pliki są chronione przez SIP, użyj lspolecenia z kreską O w Terminalu:

ls -O

Pliki chronione SIP będą oznaczone jako ograniczone .

Należy pamiętać, że nawet jeśli dowiązanie symboliczne jest chronione przez SIP, nie musi to oznaczać, że katalog, do którego prowadzą łącze, jest chroniony przez SIP. Na poziomie głównym dysku rozruchowego El Capitan w systemie OS X znajduje się kilka dowiązań symbolicznych chronionych przez SIP, wskazujących katalogi przechowywane w katalogu o nazwie root private.

Jednak podczas privatesprawdzania zawartości katalogu katalogi wskazywane przez te dowiązania symboliczne nie są chronione przez SIP i zarówno one, jak i ich zawartość mogą być przenoszone, edytowane lub zmieniane przez procesy z wykorzystaniem uprawnień administratora.

Oprócz listy wyjątków SIP, którą wprowadził Apple rootless.conf, istnieje druga lista wyjątków SIP. Ta lista zawiera wiele katalogów i nazw aplikacji dla produktów innych firm. rootless.confTa lista wykluczeń jest podobna do Apple i wszelkie zmiany stron trzecich zostaną zastąpione przez Apple.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Ochrona środowiska wykonawczego

Zabezpieczenia SIP nie ograniczają się do ochrony systemu przed zmianami systemu plików. Istnieją również wywołania systemowe, których funkcjonalność jest obecnie ograniczona.

• task_for_pid () / Processor_set_tasks () kończy się niepowodzeniem z EPERM
• Mach specjalne porty są resetowane przy exec (2)
• Różne zmienne środowiskowe są ignorowane
• Sondy DTrace są niedostępne

Jednak SIP nie blokuje kontroli przez programistę własnych aplikacji podczas ich opracowywania. Narzędzia Xcode będą nadal pozwalały na sprawdzanie i debugowanie aplikacji podczas procesu programowania.

Aby uzyskać więcej informacji na ten temat, polecam przejrzeć dokumentację programistyczną Apple dotyczącą SIP .

Ochrona rozszerzenia jądra

SIP blokuje instalację niepodpisanych rozszerzeń jądra. Aby zainstalować rozszerzenie jądra w systemie OS X El Capitan z włączonym SIP, rozszerzenie jądra musi:

1. Być podpisanym przy użyciu ID dewelopera do podpisywania certyfikatu Kexts
2. Zainstaluj w / Library / Extensions

Jeśli instalujesz niepodpisane rozszerzenie jądra, SIP musi być najpierw wyłączone.

Aby uzyskać więcej informacji na temat zarządzania SIP, spójrz na poniższy link:

Ochrona integralności systemu - dodanie kolejnej warstwy do modelu bezpieczeństwa Apple