Existe-t-il des appareils Google qui prennent en charge les fonctionnalités de leur noyau par défaut?

Si j'ai rooté sans système (aucune modification sur la /systempartition) un appareil Nexus, serais-je capable de définir des capacités sur les exécutables sans changer le binaire du noyau d'origine?

Je souhaite souvent gérer des fichiers sans restrictions depuis mon terminal (obligatoire CAP_DAC_READ_SEARCH) . Cependant, je souhaite également ne pas utiliser le superutilisateur.
Les éléments requis sont des outils pour définir des plafonds le long du support du noyau pour les utiliser (il ne dépend pas d'autres choses de l'espace utilisateur) .

Le problème est que je ne possède pas un tel appareil. Je ne peux donc pas dire si cela fonctionnerait sur l'un ou l'autre Nexus 5X Nexus 6P Nexus 9 Pixel C.

— user2284570
source

J'ai également été incapable de trouver un émulateur nexus…

— user2284570

J'en doute ... Puisque Android utilise Bionic libc et non la bibliothèque standard GNU libc (glibc), il n'est même pas proche de la compatibilité POSIX. Vous pourriez peut-être compiler votre propre noyau avec une libc différente comme CrystaX NDK au lieu de Bionic, mais je ne sais pas si ces fonctionnalités sont là-dedans non plus.

— acejavelin

@acejavelin: la partie userland n'est requise que pour définir des attributs étendus contenant des capacités. Tout le reste est côté noyau. Je viens de remarquer que la /system/bin/pingcommande n'est pas configurée sur mon véritable appareil Samsung, ce qui suggère CAP_NET_RAW. Cependant, je ne rooterai pas un véritable appareil et je ne sais pas quel outil je peux utiliser pour voir les informations pertinentes, donc je ne peux pas vérifier.

— user2284570

Pourquoi ne rooteriez-vous pas un appareil Nexus? Il est destiné à cela et n'annule pas votre garantie. Il est très simple de restaurer n'importe quel appareil Nexus à son état par défaut, non racine et verrouillé, l'appareil est fondamentalement non brique.

— acejavelin

@acejavelin: Je ne possède pas d'appareil Nexus… Mon objectif est la recherche en matière de sécurité et Google ne récompense que ses propres appareils. J'ai donc besoin de savoir si le noyau d'un des appareils de ma question prend en charge les capacités xattr. Ce que je vois sur mon onglet Galaxy est probablement uniquement lié à Samsung. Si je n'implique pas l'enracinement dans ma question, elle pourrait être fermée car peu claire .

— user2284570

Bien que la question soit ancienne, elle continue d'apparaître au-dessus des questions sans réponse (mes balises) . Je pense donc que je devrais répondre à cette question :)

SOUTIEN DE L'AOSP AUX CAPACITÉS:

La question concerne spécifiquement les appareils Google, je n'ai jamais utilisé d'appareil Google. Cependant, ce que je peux dire avec certitude, c'est que les capacités Linux (processus) doivent avoir été activées sur la plupart des appareils (sinon tous) fonctionnant aussi bas que Android 1.6. La référence se trouve dans initet system_server, les deux composants très principaux de l'AOSP. Dans Android 4.2, par exemple, installd- un autre composant de base - a été conçu pour fonctionner avec des capacités abandonnées.

Les capacités du système de fichiers ont été l'une des principales améliorations de la sécurité d'Android 4.3 qui ont supprimé set-uid/ set-giddes fichiers binaires comme run-as, en définissant des capacités de fichier sur eux. Cela a provoqué des changements révolutionnaires dans le parcours d'enracinement d'Android.

La prise en charge des capacités ambiantes a été ajoutée dans Android 8, ce qui décourage l'utilisation des capacités de fichiers:

Les capacités de fichiers, à leur tour, présentent un risque pour la sécurité, car tout processus exécutant un fichier avec des capacités de fichiers pourra gagner ces capacités.

De nombreux initservices en dépendent, par exemple storaged, le mien sshdet mes dnscrypt-proxyservices.

LE SOUTIEN DE KERNEL AUX CAPACITÉS:

En ce qui concerne la partie noyau, la construction du noyau sans capacités n'est pas facultative:

Du noyau 2.5.27 au noyau 2.6.26, les capacités étaient un composant facultatif du noyau, et pouvaient être activées / désactivées via l' option de configuration du noyau CONFIG_SECURITY_CAPABILITIES .

Et:

Dans les noyaux avant Linux 2.6.33, les capacités des fichiers étaient une fonctionnalité facultative configurable via l' option CONFIG_SECURITY_FILE_CAPABILITIES . Depuis Linux 2.6.33, l'option de configuration a été supprimée et les capacités des fichiers font toujours partie du noyau.

La version la plus ancienne du noyau commun sur les référentiels Android est 2.6.39 qui inclut également la prise en charge des capacités de fichier.

La prise en charge des capacités du système de fichiers côté noyau a dû être retardée par certains OEM, mais ils ont dû changer, car sinon les fonctionnalités se briseraient. Par exemple surfaceflinger(le composeur de surface d'Android ) ne fonctionnera pas sans capacités de fichier depuis Android 7.1.

Le noyau Linux principal 4.3 a été corrigé en septembre 2015 pour les capacités ambiantes (processus), rétroporté vers les noyaux Android 3.18 et 4.1 en 2016. Ils font donc nécessairement partie du noyau.

CONCLUSION:

Sur les distributions Linux, très peu de programmes utilisent les capacités de Linux. Bien qu'il y ait pam_cap, pour la plupart (ou tous?) Distros utilisent encore set-uidsur su, sudo, ping, mount, passwdet ainsi de suite. Mais sur Android, les capacités sont profondément intégrées dans le cadre et les services de base. Pour les supprimer, il faudrait éditer des centaines ou des milliers de lignes dans AOSP et la source du noyau. Cela n'a aucun sens qu'un OEM (en particulier Google, qui a développé AOSP et modifié le noyau Linux pour Android) n'utilise pas cette fonctionnalité de sécurité gratuite lorsqu'elle est facilement disponible dans le noyau Android. Il s'agit d'une fonctionnalité purement liée au système d'exploitation, qui ne nécessite aucun support matériel supplémentaire. Ainsi, tout téléphone de n'importe quel fabricant doit avoir des capacités prises en charge.

DES QUESTIONS:

serais-je capable de définir des capacités sur les exécutables sans changer le binaire du noyau d'origine?

Oui, tu dois l'être.

Les choses nécessaires sont des outils pour fixer les plafonds ...

J'utilise capsh, getcap, setcap, à getpcapspartir libcapet netcap, à pscappartir libcap-ngsans aucun problème. Mais je préfère les capacités ambiantes, celles-ci sont faciles à configurer et ne dépendent d'aucune fonctionnalité du système de fichiers comme les attributs étendus comme dans le cas des capacités de fichier. Vous pouvez également utiliser listxattr, getxattr, setxattret des removexattroutils de xattr_syscall_wrappermanipuler security.capabilityou de toute autre xattr directement.

De votre commentaire:

Je viens de remarquer que la /system/bin/pingcommande n'est pas setuidsur mon vrai appareil Samsung, suggérantCAP_NET_RAW

Le ping d'Android n'a set-uidni CAP_NET_RAW. Il crée un socket spécial non-RAW IPPROTO_ICMP qui - contrairement à IPPROTO_RAW- ne nécessite aucun privilège.

AUTRES RÉFÉRENCES:

En plus de plus de 10 références données ci-dessus, voici quelques autres parties du code AOSP prenant en charge et utilisant les capacités Linux:

Les composantes de base: Bionic libc, init, trusty(OS)
Composants externes: libcap ,libcap-ng
Daemons / services: zygote (applications fourchues et system_server), hostapd, wpa_supplicant, dnsmasq, logd, netd( NetLinkgestionnaire, DNS privé), debuggerd(test), sdcarddémon, performanced, incidentd, mtpd, traced_probes(perfetto), racoon(IPSec), wificondun certain nombre de daemons HAL y compris rild.
Exécutables: reboot (init), dumpstate, tcpdump, strace, iputils( ping, tracerouteetc.)
Minijail: un outil de sandboxing dédié et une bibliothèque qui tourne autour des capacités. adbdutilise cette bibliothèque pour supprimer les privilèges.
SELinux utilise la capabilityclasse pour accorder / refuser des capacités aux domaines.

Il conclut qu'Android dépend fortement des capacités de Linux, ce n'est pas une fonctionnalité peu utilisée .

EN RELATION:

— Irfan Latif
source

Ne répond à rien du tout. Tout ce que vous avez déclaré est connu. Le point de la question est qu'il est peu utilisé, c'est si les appareils de marque Google l'incluent.

— user2284570