2016-02-17 2 views
0

Je voudrais accorder des permissions Android (ex: android.permission.DELETE_PACKAGES, qui a protectionLevel = system | signature) à des applications signées par une signature donnée et/ou avec un nom de paquet donné des politiques SELinux, mais jusqu'ici je n'ai pas pas trouvé un moyen qui fonctionne. Le fichier mac_permissions.xml utilisé pour accepter une balise allow-permission qui accepte les chaînes d'autorisation Android, mais based on the Lollipop code qui l'analyse, cette balise ne semble plus être prise en charge. J'ai essayé de l'utiliser quand même, et cela semblait définitivement ignoré par le système.Est-il possible de connecter la stratégie SELinux aux autorisations Android?

Idéalement, je n'aurais qu'à ajouter/modifier des fichiers de stratégie SELinux par opposition aux fichiers AndroidManifest centraux qui déclarent les autorisations restreintes et spécifient leurs niveaux de protection. Supposons que les applications avec la signature/le package donné ne se voient pas accorder ces autorisations par PackageManager car elles ne possèdent aucun des privilèges spéciaux reconnus par les niveaux de protection des autorisations Android (signés par le certificat de plate-forme, installé dans/system, etc.). l'autorisation est une autorisation système (c'est-à-dire déclarée par le frameworks/base/core/res AndroidManifest) déclarée lors de la génération du système d'exploitation.

Existe-t-il un moyen de permettre à une signature/à un package donné d'utiliser une autorisation Android donnée de SELinux?

Répondre

2

Tout le travail de MMAC a été abandonné par le projet SE pour Android, car aucun d'entre eux n'a été accepté en amont. Actuellement, il n'existe aucun mécanisme pris en charge pour associer des autorisations de package à la stratégie SE Linux. Si votre bâtiment Android, on pourrait restaurer ce travail dans leur arbre, les branches pour commencer sont les branches seandroid ici: https://bitbucket.org/seandroid/frameworks-base/branches/

Cependant, les branches les plus à jour avec le code ont plus d'un an. Vous pouvez donc avoir des problèmes de portage.

En outre, ce code utilise le fichier mac_permissions.xml pour contrôler l'accès, mais les PSTE, les opérations étendues des changements serait également l'utilisation, vous pouvez lire à ce sujet dans son fichier de configuration: https://bitbucket.org/seandroid/external-sepolicy/src/ccb97c52cda2bac69c0499b3c76bc8e0d28d636c/eops.xml?at=seandroid-5.1.1&fileviewer=file-view-default

Ours en En effet, les contrôles d'autorisation d'installation et les changements d'eops, tout en fournissant une forme de contrôle d'accès obligatoire, n'utilisent pas vraiment les technologies SE Linux. Par cela, il peut être utilisé avec ou sans un noyau activé par selnux. Si l'on voulait vraiment coupler SE Linux à des chaînes d'autorisation, il faudrait déployer des efforts considérables pour étiqueter les autorisations, et demander à Package Manager Service (PMS) et Activity Manager Service (AMS) de calculer si l'accès est autorisé ou non. Toutefois, maintenant que les contrôles d'autorisation android par application sont disponibles, la plupart du travail n'est plus nécessaire.

+0

Je ne vois pas eops.xml sous external/sepolicy de la dernière version de Lollipop AOSP (https://android.googlesource.com/platform/external/sepolicy/+/lollipop-mr1-release); est-ce que cela n'a pas été accepté en amont? – CCJ