Чи є пристрої Google, які підтримують можливості в ядрі за замовчуванням?

Якщо я безсистемного кореня (не було зроблено жодної модифікації для /systemрозділу) пристрою Nexus, чи зможу я встановити можливості на виконувані файли, не змінюючи початковий двійковий код ядра?

Я часто хочу керувати файлами без обмежень зі свого терміналу (вимагаю CAP_DAC_READ_SEARCH) . Однак я також хочу не використовувати суперпользователь.
Необхідні речі - це інструменти для встановлення кришок уздовж підтримки ядра для їх використання (він не покладається на інші речі в просторі користувача) .

Проблема в тому, що я не володію таким пристроєм. Тому я не можу сказати, чи спрацювало б це на будь-якому з Nexus 5X Nexus 6P Nexus 9 Pixel C.

Хоча питання давнє, воно все ще з’являється вгорі питань без відповіді (мої теги) . Тому я думаю, що я повинен відповісти на це :)

ПІДТРИМКА AOSP ДЛЯ МОЖЛИВОСТІ:

Питання стосується конкретно пристроїв Google, я ніколи не використовував пристрій Google. Однак я можу сказати напевно, що можливості Linux (процес) повинні бути включені на більшості пристроїв (якщо не на всіх), які працюють так само низько, як Android 1.6. Посилання знаходиться в initі system_server, як дуже основних компонентів AOSP. Наприклад, в Android 4.2 installd- ще один основний компонент - був створений для роботи зі зниженими можливостями.

Можливості файлової системи були одним з головних поліпшень безпеки в Android 4.3, який видаляв set-uid/ використовував set-gidтакі файли, як run-asвстановлення можливостей файлів. Це спричинило революційні зміни у вкоріненому шляху Android.

Підтримка можливостей Ambient була додана в Android 8, що відмовляє від використання можливостей файлів:

Файлові можливості, у свою чергу, становлять ризик для безпеки, оскільки будь-який процес, що виконує файл із можливостями файлу, зможе отримати ці можливості.

Багато initпослуг залежать від них, наприклад storaged, зокрема мої власні sshdта dnscrypt-proxyпослуги.

ПІДТРИМКА КЕРНЕЛУ ДЛЯ МОЖЛИВОСТІ:

Перехід до частини ядра, створення ядра без можливостей не є обов’язковим:

Від ядра 2.5.27 до ядра 2.6.26, можливості були необов’язковим компонентом ядра, і їх можна було включити / відключити за допомогою параметра конфігурації ядра CONFIG_SECURITY_CAPABILITIES .

І:

У ядрах до Linux 2.6.33 можливості файлів були необов'язковою функцією, яку можна налаштувати за допомогою параметра CONFIG_SECURITY_FILE_CAPABILITIES . З моменту Linux 2.6.33 параметр конфігурації видалено, а можливості файлів завжди є частиною ядра.

Найдавніша поширена версія ядра в сховищах Android - 2.6.39, яка також підтримує можливості файлів.

Підтримка можливостей файлової системи на стороні ядра, мабуть, була відкладена у деяких виробників оригіналу, але вони повинні були переключитися, оскільки в іншому випадку функціональність порушиться. Наприклад surfaceflinger(Android) поверхневий композитор ) не працюватиме без можливостей файлів, оскільки Android 7.1.

Магістраль Linux ядро 4.3 було виправлено в в Sep'15 для навколишнього середовища (процес) можливостей, портований для Android ядра 3.18 і 4.1 в 2016 році Таким чином , вони обов'язково частина ядра.

ВИСНОВОК:

У дистрибутивах Linux дуже небагато програм використовують можливості Linux. Хоча є pam_cap, в основному (або все?) Дистрибутиви до сих пір використовують set-uidна su, sudo, ping, mount, passwdі так далі. Але можливості Android глибоко інтегровані в рамкові та основні сервіси. Для їх видалення знадобиться редагування сотень або може бути тисячі рядків у AOSP та джерелі ядра. Немає сенсу, що OEM (зокрема Google, який розробив AOSP і модифікував ядро ​​Linux для Android) не використовував цю функцію безкоштовного захисту, коли вона доступна в ядрі Android. Це чиста функція, пов’язана з ОС, не вимагає додаткової апаратної підтримки. Отже, будь-який телефон будь-якого виробника повинен підтримувати можливості.

ЗАПИТАННЯ:

Чи зможу я встановити можливості на виконувані файли, не змінюючи початковий двійковий код ядра?

Так, ти повинен бути.

Необхідні речі - це інструменти для встановлення кришок ...

Я використовую capsh, getcap, setcap, getpcapsз libcapі netcap, pscapз libcap-ngбез будь - яких проблем. Але я віддаю перевагу можливостям Ambient, їх легко налаштувати і не залежать від будь-яких функцій файлової системи, таких як Extended Attributes, як у випадку з можливостями файлів. Ви також можете використовувати listxattr, та getxattr, setxattrі removexattrінструменти, xattr_syscall_wrapperщоб безпосередньо маніпулювати security.capabilityчи будь-яким іншим XATTR.

З вашого коментаря:

Щойно я помітив, що /system/bin/pingкоманда відсутня setuidна моєму реальному пристрої Samsung, що говоритьCAP_NET_RAW

Android ping ні має, set-uidні CAP_NET_RAW. Він створює спеціальний не-RAW- сокет, IPPROTO_ICMPякий, на відміну від IPPROTO_RAWнього, не вимагає ніяких привілеїв.

ДОДАТКОВІ ЛІТЕРАТУРИ:

На додаток до 10+ посилань, наведених вище, ось кілька інших частин коду AOSP, що підтримують та використовують можливості Linux:

• Основні компоненти: Bionic libc, init, trusty(ОС)
• Зовнішні компоненти: libcap ,libcap-ng
• Демони / послуги: zygote (роздвоєні додатки і system_server), hostapd, wpa_supplicant, dnsmasq, logd, netd( NetLinkменеджер, приватний DNS), debuggerd(тест), sdcardдемон, performanced, incidentd, mtpd, traced_probes(Perfetto), racoon(IPSec), wificondряд HAL демонів , включаючиrild .
• Виконувані: reboot (INIT), dumpstate, tcpdump, strace, iputils( ping, і tracerouteт.д.)
• Minijail: спеціальний інструмент і бібліотека для пісочниці, яка обертається навколо можливостей. adbdвикористовує цю бібліотеку для скасування привілеїв.
• SELinux використовує capabilityклас для надання / заборони можливостей доменам.

Звідси робиться висновок, що Android сильно залежить від можливостей Linux, це не мало використовувана функція.

ПОВ'ЯЗАНІ:

• Які спеціальні привілеї “/ system / xbin / su” має доступ до кореневого файлу wrt?
• Дозволи, можливості користувача Root та Linux: Linux проти Android