Czy są jakieś urządzenia Google, które obsługują funkcje w domyślnym jądrze?


14

Jeśli bezsystemowy root (bez modyfikacji /systempartycji) urządzenia Nexus, będę w stanie ustawić możliwości plików wykonywalnych bez zmiany oryginalnego pliku binarnego jądra?

Często chcę zarządzać plikami bez ograniczeń z mojego terminala (wymagają CAP_DAC_READ_SEARCH) . Chcę też nie używać superużytkownika.
Wymagane są narzędzia do ustawiania limitów wraz z obsługą jądra do ich używania (nie zależy to od innych rzeczy w przestrzeni użytkownika) .

Problem polega na tym, że nie posiadam takiego urządzenia. Więc nie mogę powiedzieć, czy to zadziała na którymkolwiek Nexus 5X Nexus 6P Nexus 9 Pixel C.


2
Nie mogłem też znaleźć emulatora nexusa…
user2284570 11.04.16

Wątpię w to ... Ponieważ Android używa Bionic libc, a nie standardowej biblioteki GNU libc (glibc), nie jest nawet zgodny z POSIX. Możesz być w stanie skompilować własne jądro z innym libc, takim jak CrystaX NDK zamiast Bionic, ale nie wiem, czy te funkcje są w tym zawarte.
acejavelin 12.04.16

@acejavelin: część dotycząca użytkowników jest wymagana tylko do ustawiania rozszerzonych atrybutów zawierających możliwości. Cała reszta jest po stronie jądra. Właśnie zauważyłem, że /system/bin/pingpolecenie to nie jest setuid na moim prawdziwym urządzeniu Samsung, co sugeruje CAP_NET_RAW. Jednak nie zrootuję prawdziwego urządzenia i nie wiem, którego narzędzia mogę użyć do wyświetlenia odpowiednich informacji, więc nie mogę sprawdzić.
user2284570 12.04.16

Dlaczego nie zrootowałeś urządzenia Nexus? Jest przeznaczony do tego i nie unieważnia gwarancji. Przywrócenie dowolnego urządzenia Nexus do stanu domyślnego, niezakotwionego i zablokowanego jest bardzo proste, w zasadzie urządzenie nie jest możliwe do odtworzenia.
acejavelin 12.04.16

@acejavelin: Nie posiadam urządzenia Nexus… Moim celem są badania bezpieczeństwa, a Google wynagradza tylko za własne urządzenia. Muszę więc wiedzieć, czy jądro jednego z urządzeń w moim pytaniu obsługuje funkcje xattr. To, co widzę na mojej karcie galaktyki, prawdopodobnie dotyczy tylko Samsunga. Jeśli nie włączę rootowania w moim pytaniu, może zostać zamknięte jako niejasne .
user2284570 12.04.16

Odpowiedzi:


1

Chociaż pytanie jest stare, wciąż pojawia się nad pytaniami bez odpowiedzi (moje tagi) . Myślę więc, że powinienem na to odpowiedzieć :)

WSPARCIE AOSP DLA MOŻLIWOŚCI:

Pytanie dotyczy w szczególności urządzeń Google. Nigdy nie korzystałem z urządzenia Google. Mogę jednak powiedzieć na pewno, że funkcje Linux (proces) musiały być włączone na większości urządzeń (jeśli nie wszystkich) z tak niskim poziomem jak Android 1.6. Odniesienia można znaleźć w initi system_server, zarówno bardzo podstawowych elementach AOSP. Na przykład w Androidzie 4.2 installd- innym kluczowym składniku - działał z upuszczonymi możliwościami.

Możliwości systemu plików były jednym z głównych Ulepszeń bezpieczeństwa w Androidzie 4.3, które usunęły set-uid/ set-gidz plików binarnych, takie jak run-asustawienie na nich możliwości plików. Spowodowało to rewolucyjne zmiany w rootowaniu Androida.

W systemie Android 8 dodano obsługę funkcji Ambient, która zniechęca do korzystania z funkcji plików:

Funkcje plików z kolei stanowią zagrożenie dla bezpieczeństwa, ponieważ każdy proces wykonujący plik z funkcjami plików będzie mógł uzyskać te możliwości.

Wiele initusług zależy od nich, np. storagedMoje sshdi dnscrypt-proxyusługi.

WSPARCIE KERNELA DLA MOŻLIWOŚCI:

Jeśli chodzi o część jądra, budowanie jądra bez możliwości nie jest opcjonalne:

Od jądra 2.5.27 do jądra 2.6.26 możliwości były opcjonalnym składnikiem jądra i można je włączać / wyłączać za pomocą opcji konfiguracyjnej jądra CONFIG_SECURITY_CAPABILITIES .

I:

W jądrach wcześniejszych niż Linux 2.6.33 możliwości plików były opcjonalną funkcją konfigurowalną za pomocą opcji CONFIG_SECURITY_FILE_CAPABILITIES . Od Linuksa 2.6.33 opcja konfiguracji została usunięta, a możliwości plików są zawsze częścią jądra.

Najstarsza popularna wersja jądra w repozytoriach Androida to 2.6.39, która obejmuje także obsługę plików.

Obsługa możliwości systemu plików po stronie jądra musiała być opóźniona przez niektórych producentów OEM, ale musieli się przełączyć, ponieważ w przeciwnym razie funkcje uległyby awarii. Na przykład surfaceflinger( kompozytor powierzchniowy Androida ) nie będzie działać bez możliwości obsługi plików od Androida 7.1.

Główne jądro Linuksa 4.3 zostało załatane we wrześniu 15 dla funkcji Ambient (procesowych), w 2016 r. Zostało przeniesione do jądra Androida 3.18 i 4.1. Dlatego są one koniecznie częścią jądra.

WNIOSEK:

W dystrybucjach Linuksa bardzo niewiele programów korzysta z możliwości Linuksa. Choć nie jest pam_cap, w większości (lub wszystkich?) Dystrybucje nadal korzystać set-uidna su, sudo, ping, mount, passwdi tak dalej. Ale w Androidzie możliwości są głęboko zintegrowane z usługami szkieletowymi i podstawowymi. Ich usunięcie wymagałoby edycji setek lub może być tysięcy linii w AOSP i źródle jądra. Nie ma sensu, aby producent OEM (zwłaszcza Google, który opracował AOSP i zmodyfikował jądro Linuksa dla Androida), nie korzysta z tej bezpłatnej funkcji bezpieczeństwa, gdy jest łatwo dostępny w jądrze Androida. Jest to funkcja związana wyłącznie z systemem operacyjnym, nie wymaga dodatkowego wsparcia sprzętowego. Tak więc każdy telefon dowolnego producenta musi mieć obsługiwane funkcje.


PYTANIA:

czy byłbym w stanie ustawić możliwości plików wykonywalnych bez zmiany oryginalnego pliku binarnego jądra?

Tak, musisz być.

Wymagane są narzędzia do ustawiania czapek ...

Używam capsh, getcap, setcap, getpcapsz libcap, a netcap, pscapze libcap-ngbez żadnych problemów. Ale wolę możliwości Ambient, te są łatwe do skonfigurowania i nie zależą od żadnych funkcji systemu plików, takich jak Rozszerzone Atrybuty, jak w przypadku możliwości plików. Można również użyć listxattr, getxattr, setxattri removexattrnarzędzi z xattr_syscall_wrappermanipulowania security.capabilitylub inny xattr bezpośrednio.

Z twojego komentarza:

Właśnie zauważyłem, że /system/bin/pingpolecenia nie ma setuidna moim prawdziwym urządzeniu Samsung, co sugerujeCAP_NET_RAW

Ping Androida nie ma set-uidani CAP_NET_RAW. Tworzy specjalne gniazdo inne niż RAW,IPPROTO_ICMP które - w przeciwieństwie do IPPROTO_RAW- nie wymaga żadnych uprawnień.


DALSZE REFERENCJE:

Oprócz ponad 10 referencji podanych powyżej, oto kilka innych części kodu AOSP obsługujących i wykorzystujących możliwości Linuksa:

  • Składniki podstawowe: Bionic libc, init, trusty(OS)
  • Elementy zewnętrzne: libcap ,libcap-ng
  • Demony / Usługi: zygote (rozwidlone aplikacje i system_server), hostapd, wpa_supplicant, dnsmasq, logd, netd( NetLinkkierownik, prywatne DNS), debuggerd(test), sdcarddemon, performanced, incidentd, mtpd, traced_probes(perfetto), racoon(IPSec) wificond, liczba demonów HAL włącznie rild.
  • Wykonywalne: reboot (startowych), dumpstate, tcpdump, strace, iputils( ping, tracerouteetc.)
  • Minijail: Dedykowane narzędzie i biblioteka piaskownicy, które obracają się wokół możliwości. adbdkorzysta z tej biblioteki do usuwania uprawnień.
  • SELinux używa capabilityklasy do przyznawania / odmawiania możliwości domenom.

Dochodzi do wniosku, że Android bardzo zależy od możliwości Linuksa, nie jest to mało używana funkcja.


ZWIĄZANE Z:


W ogóle nic nie odpowiada. Wszystko co powiedziałeś jest znane. Chodzi o to, że jest mało używany, jeśli urządzenia marki Google go zawierają.
user2284570,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.