Y a-t-il des appareils Google qui supportent les capacités dans leur noyau par défaut ?

Bien que la question soit ancienne, elle continue d'apparaître en tête de liste des Sans réponse (mes tags) questions. Je pense donc que je devrais répondre à cette question :)

LE 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 de Linux (processus) doivent avoir été activées sur la plupart des appareils (si ce n'est tous) fonctionnant sous Android 1.6. La référence se trouve dans init y system_server qui sont tous deux des composants très importants de l'AOSP. Dans Android 4.2, par exemple, installd - un autre composant central - a été conçu pour fonctionner avec des capacités réduites.

Capacités du système de fichiers étaient l'un des principaux Améliorations de la sécurité dans Android 4.3 qui a retiré set-uid / set-gid à partir de binaires comme run-as en définissant les capacités des fichiers. Cela a provoqué des changements révolutionnaires dans l'aventure de l'enracinement d'Android.

Soutien aux Capacités ambiantes a été ajouté dans Android 8 qui décourage l'utilisation des capacités du dossier :

Les capacités des fichiers, à leur tour, présentent un risque pour la sécurité puisque tout processus exécutant un fichier avec des capacités de fichier sera en mesure d'obtenir ces capacités.

Beaucoup de init les services en dépendent, par exemple storaged y compris la mienne sshd y dnscrypt-proxy services.

LE SUPPORT DU NOYAU POUR LES CAPACITÉS :

Pour en venir à la partie noyau, la construction du noyau sans capacités n'est pas facultatif :

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 par l'intermédiaire de la commande CONFIG_SECURITY_CAPABILITIES option de configuration du noyau.

Et :

Dans les noyaux antérieurs à Linux 2.6.33, les capacités des fichiers étaient une fonctionnalité optionnelle configurable via le paramètre CONFIG_SECURITY_FILE_CAPABILITIES option. 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 dépôts Android est la 2.6.39 qui comprend la prise en charge des capacités des fichiers également.

Le support des capacités du système de fichiers du côté du noyau doit avoir été retardé de certains équipementiers, mais ils ont dû changer, car sinon, les fonctionnalités auraient été interrompues. Par exemple surfaceflinger (Android compositeur de surface ) ne fonctionnera pas sans les capacités du fichier depuis Android 7.1.

La version principale du noyau Linux 4.3 a été corrigée en septembre 15 pour les capacités du processus Ambient, backported au noyau d'Android 3.18 et 4.1 en 2016. Ils font donc nécessairement partie du noyau.

CONCLUSION :

Sur les distributions Linux, un très peu utilisent les capacités de Linux. Bien qu'il y ait pam_cap la plupart (ou toutes ?) des distributions utilisent toujours set-uid sur su , sudo , ping , mount , passwd et ainsi de suite. Mais sur Android, les capacités sont profondément intégrées dans le cadre et les services de base. Les supprimer nécessiterait de modifier des centaines, voire des milliers de lignes dans les sources de l'AOSP et du noyau. Il n'est pas logique qu'un OEM (en particulier Google, qui a développé l'AOSP et modifié le noyau Linux pour Android) ne fasse pas usage de cette possibilité. gratuit la fonction de sécurité quand elle est disponible dans le noyau d'Android. Il s'agit d'une fonction purement liée au système d'exploitation, qui ne nécessite aucun support matériel supplémentaire. Donc n'importe quel téléphone de n'importe quel fabricant doit avoir des capacités supportées.

QUESTIONS :

Serais-je en mesure de définir les capacités des exécutables sans modifier le binaire original du noyau ?

Oui, vous devez l'être.

Les éléments nécessaires sont les outils pour poser les bouchons ...

J'ai utilisé capsh , getcap , setcap , getpcaps de libcap y netcap , pscap de libcap-ng sans aucun problème. Mais je préfère les capacités ambiantes, qui sont faciles à configurer et ne dépendent d'aucune fonctionnalité du système de fichiers comme Attributs étendus comme dans le cas des capacités de fichiers. Vous pouvez également utiliser listxattr , getxattr , setxattr y removexattr outils de xattr_syscall_wrapper à manipuler security.capability ou tout autre XATTR directement.

D'après votre commentaire :

Je viens de remarquer que le /system/bin/ping n'est pas setuid sur mon vrai appareil Samsung, ce qui suggère CAP_NET_RAW

Android ping ni l'un ni l'autre n'a set-uid ni CAP_NET_RAW . Il crée une atmosphère spéciale non-RAW prise de courant IPPROTO_ICMP qui - contrairement à IPPROTO_RAW - ne nécessite aucun privilège.

AUTRES RÉFÉRENCES :

En plus des 10+ références données ci-dessus, voici quelques autres parties du code de l'AOSP supportant et utilisant les capacités de Linux :

• Composants essentiels : Bionic libc , init , trusty (OS)
• Composants externes : libcap , libcap-ng
• Daemons / services : zygote (applications en fourche et system_server ), hostapd , wpa_supplicant , dnsmasq , logd , netd ( NetLink gestionnaire, DNS privé), debuggerd (test), sdcard démon, performanced , incidentd , mtpd , traced_probes (perfetto), racoon (IPSec), wificond un certain nombre de démons HAL, notamment rild .
• Exécutables : reboot (init), dumpstate , tcpdump , strace , iputils ( ping , traceroute etc.)
• Mini-prison : Un outil de sandboxing dédié et une bibliothèque qui tourne autour des capacités. adbd se sert de cette bibliothèque pour déposer des privilèges.
• SELinux utilise capability pour accorder ou refuser des capacités aux domaines.

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

RELATION :

• Quels sont les privilèges spéciaux de "/system/xbin/su" par rapport à l'accès à la racine ?
• Permissions, utilisateur racine et capacités de Linux : Linux vs. Android