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

242

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?

Josh
źródło
8
„Co to właściwie oznacza dla wygody użytkownika i doświadczenia programisty?” Korzystam z wersji beta, odkąd jest dostępna, i to pierwszy raz, kiedy o niej słyszałem. sudoa monitowanie o hasło działało normalnie / poprzednio / oczekiwano. Prawdopodobnie odpowiedź brzmi: „przez większość czasu nie zauważysz; kiedy to zrobisz, zauważysz trudny”.
OJFord,
3
To proste - naśladowanie błędów jest funkcją.
Wolfgang Fahl,
Jeśli ktoś przypadkowo usunie plik /usr/locali nie będzie mógł go odtworzyć, zobacz tę odpowiedź tutaj .
Lloeki,

Odpowiedzi:

280

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 ).

Gordon Davisson
źródło
1
Fajnie dzięki. Zadałem to pytanie, ponieważ miałem już zamieścić link do tego artykułu quora na innym pytaniu Stack Exchange, a potem zdałem sobie sprawę, że to nie był właściwy ruch ;-)
Josh
15
... To całkowicie sprawia, że ​​chcę napisać kextcoś lub coś, co pozwoli mi stworzyć plik binarny, który mogę uruchomić w wierszu poleceń, aby powrócić do nieograniczonego dostępu!
Josh
1
@Vladimir Niestety, nie mam żadnych informacji wewnętrznych na temat planów Apple. Domyślam się, że pozostanie w przewidywalnej przyszłości, chociaż nie zdziwiłbym się, gdyby zmienił się (i sam SIP) znacząco w kilku kolejnych wersjach.
Gordon Davisson,
5
Są chwile, kiedy nienawidzę Apple. Doceniam utrudnienie strzelenia sobie w stopę (lata temu przypadkowo złapałem plik tekstowy w moim MBR na Linuksie), ale są chwile, kiedy trzeba np. Umieścić dodatkowy link w / usr / bin i mieć przejście przez proces wyłączania ładnej ochrony w tym celu jest zbyt paternalistyczne i denerwujące. Wystarczyłoby dodatkowe okno dialogowe z ostrzeżeniami.
Mars
2
Mniej inwazyjnym sposobem wydaje się być wyłączenie SIP, edycja pliku głównego, aby usunąć ograniczenia tylko dla kilku plików binarnych, które naprawdę chcesz zastąpić, i włączenie SIP ponownie.
Joshua
92

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: wprowadź opis zdjęcia tutaj

JJ
źródło
3
Poparłem również tę odpowiedź, ponieważ nie odpowiada ona na pytanie, a mianowicie: Jaka jest funkcja „Rootless” El Capitan na poziomie technicznym? Czy sudo -s nadal będą działać, a jeśli tak, to jak zmieni się doświadczenie używania powłoki jako roota? . Ta odpowiedź wydaje się mówić tylko o DTrace
Josh
24
Myślę, że odpowiedź mówi jasno i precyzyjnie do dużej części pytania, a mianowicie, jak zmieni się doświadczenie używania powłoki jako roota. Sudo jest teraz pseudo sudo. W rzeczywistości dodano warstwę architektury. Wydaje mi się istotny. I na utrzymanie tego człowieka. Po co głosować w dół?
sas08
5
@patrix Nie rozumiem rozróżnienia epistemologicznego. Czym są i co robią oraz dlaczego istnieją, są ściśle powiązane. Na pewno ten post zacznie się en medias res mówiący o jednej funkcji, ale dobrze się rozróżnia. Pytanie „jak to zmienia sposób pracy programisty?” itp. jest w rzeczywistości otwartym i subiektywnym zaproszeniem, aby programiści mogli porozmawiać o swoich doświadczeniach. Stawianie tych pytań w zestawieniu z niejasnym i przesadzonym sprzeciwem „świat się skończy, bo nie możemy zakorzenić się” wydaje się odrzucać ideę krzywdy; to pokazuje szkodę dla doświadczenia deweloperów.
sas08
4
Nie zamierzam dodawać żadnych dodatkowych informacji, Josh, ponieważ po prostu kopiowałbym to, co powiedzieli inne odpowiedzi, i tak naprawdę nie dodawałem niczego do strony. Być może byłoby lepiej, gdyby najlepsza odpowiedź zawierała więcej informacji o tym, że DTrace już nie działa, a następnie usunęłbym tę odpowiedź jako zbędną :) Inną odpowiedzią jest po prostu kopia strony arstechnica.com/apple/2015/09/ os-x-10-11-el-capitan-the-ars-technica-review / 9 / links in the top comment, więc to też może pójść. Ale niektóre rzeczy w tej odpowiedzi, takie jak DTrace, który nie działa nawet przy wyłączonym SIP jako sudo, nie ma gdzie indziej w sieci, ale tutaj
JJ
3
Jedyną rzeczą, którą do tej pory wymyśliłem, jest to, że jeśli wyłączysz SIP dla DTrace, możesz dołączyć do procesów, które nie podlegają ograniczonym uprawnieniom, co od El Cap jest wszystkim, co pochodzi z systemem (jak Safari). Istnieje „głupi” sposób, polegający na skopiowaniu wszystkich binariów systemowych do nowego katalogu, takiego jak / rootless (o tej samej strukturze katalogów), a następnie utworzenie chroota dla / rootless. Teraz wszystko działa bez uprawnień i można je również dołączyć. Mądrzejszym sposobem jest ponowne zamontowanie systemu plików, ale boję się powiedzieć, jak / dlaczego, ponieważ Apple bez wątpienia zablokuje tę lukę ...
JJ
49

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.

wprowadź opis zdjęcia tutaj

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.

wprowadź opis zdjęcia tutaj

wprowadź opis zdjęcia tutaj

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.

wprowadź opis zdjęcia tutaj

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.

wprowadź opis zdjęcia tutaj

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 .

wprowadź opis zdjęcia tutaj

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.

wprowadź opis zdjęcia tutaj

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

Rich Trouton
źródło
4
Byłoby wspaniale, gdyby zrzuty ekranu mogły być zastąpione zwykłym tekstem, patrz: Zniechęcaj zrzuty ekranu kodu i / lub błędów .
kenorb