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

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.

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:

• Jakie specjalne uprawnienia „/ system / xbin / su” mają uprawnienia do rootowania?
• Uprawnienia, użytkownik root i możliwości systemu Linux: Linux vs. Android