Есть ли какие-либо устройства Google, которые поддерживают возможности ядра по умолчанию?

Если бы я был системным пользователем root (без изменений для /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, которая также включает поддержку файловых возможностей.

Поддержка возможностей файловой системы на стороне ядра должна была быть отложена у некоторых OEM-производителей, но они должны были переключиться, потому что в противном случае функциональные возможности сломались бы. Например surfaceflinger(Android Surface Composer ) не будет работать без файловых возможностей, начиная с Android 7.1.

Основное ядро ​​Linux 4.3 было исправлено в сентябре 15 для возможностей Ambient (процесса), перенесено на ядра 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, они просты в настройке и не зависят от функций файловой системы, таких как расширенные атрибуты, как в случае файловых возможностей. Вы также можете использовать listxattr, getxattr, setxattrи removexattrсредства от xattr_syscall_wrapperманипулирования security.capabilityили любого другого непосредственно некоторого атрибута.

Из вашего комментария:

Я только заметил, что /system/bin/pingкоманда не setuidна моем реальном устройстве Samsung, предлагаяCAP_NET_RAW

Андроида пинг ни есть , 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» имеет права суперпользователя?
• Разрешения, пользователь root и возможности Linux: Linux против Android