Une violation d'autorisation se produit lorsqu'un service tente d'effectuer une action qu'il n'est pas autorisé à exécuter. En mode d'application permissionsOnly standard, le framework Software-Defined Vehicle (SDV) vérifie si le sujet ou sa machine virtuelle (VM) dispose de l'autorisation requise déclarée dans sa règle.
Vous devez évaluer les messages de non-respect dans leur contexte de sécurité. Toutes les violations n'indiquent pas une erreur ou une tentative d'accès non autorisé.
Toutes les décisions d'autorisation sont consignées. Pour les afficher, recherchez les messages d'audit dans la sortie Logcat :
adb -s $SERIAL logcat | grep 'audit message'
Autorisation réussie
Les vérifications réussies sont consignées au niveau debug.
Cela indique que le sujet dispose de l'autorisation requise déclarée :
D SdvServiceManagerServer: instance2:com.sdv.google.sample.bar.ServiceBundleBar/instance declares permission to access com.sdv.google.sample.foo.ServiceBundleFoo#foo-rpc, audit message: ...
Autorisations manquantes et non-respect des règles
Les cas de non-respect se produisent lorsqu'une autorisation est manquante.
Cela se produit lorsque le sujet ne dispose pas de l'autorisation nécessaire, telle que client, server, publisher ou subscriber, dans sa règle d'autorisation, ou lorsque la VM du sujet ne la possède pas dans la règle au niveau de la VM.
Les informations sont consignées au niveau error :
E SdvServiceManagerServer: Authz violation. instance2:com.sdv.google.sample.bar.ServiceBundleBar/instance does not declare permission to access com.sdv.google.sample.foo.ServiceBundleFoo#foo-rpc, audit message: Subject lacks 'client' permission...
Correction
Le audit message du journal contient souvent une suggestion utile sur ce qui doit être ajouté pour résoudre un cas de non-respect.
Par exemple, vous pouvez rencontrer une erreur d'autorisation semblable à celle-ci :
Subject 'vm:com.client.Bundle/default' lacks 'client' permission for service 'com.server.TargetType' with channel 'my-unit'. Add 'client { service: "com.server.TargetType" channel: "my-unit" }' to the subject's Authz policy
Pour résoudre ce problème, ajoutez la règle au fichier textproto de la stratégie d'autorisation du sujet :
client {
service: "com.server.TargetType"
channel: "my-unit"
}
Si le message d'erreur indique qu'une autorisation est manquante dans la VM du sujet, vous devez l'ajouter à la règle au niveau de la VM, comme <vm_name>.textproto ou .default.textproto dans l'APEX com.oem.sdv.authz :
allow_server {
service: "com.server.TargetType"
channel: "my-unit"
}
Migrer depuis les LCA
Pour la rétrocompatibilité et la migration, le framework est compatible avec les modes ACLs only, Lenient et Strict qui tiennent compte des listes de contrôle d'accès (LCA) antérieures.
Mode LCA uniquement
En mode ACLs only, l'accès n'est autorisé que si les LCA le permettent. Les autorisations sont ignorées. Si les LCA refusent l'accès, une erreur est consignée :
E SdvServiceManagerServer: Authz violation. com.sdv.google.sample.foo.ServiceBundleFoo#foo-rpc denies access to instance2:com.sdv.google.sample.bar.ServiceBundleBar/instance, audit message: ...
Mode tolérant
En mode Lenient, l'accès est autorisé si les LCA ou les autorisations le permettent.
Si l'accès est accordé à l'aide de LCA, mais que des autorisations sont manquantes, cela est enregistré comme un non-respect mineur au niveau debug pour vous aider à identifier les autorisations manquantes tout en maintenant le système fonctionnel :
D SdvServiceManagerServer: Permissions Authz violation (access granted by ACLs): instance2:com.sdv.google.sample.bar.ServiceBundleBar/instance does not declare permission to access com.sdv.google.sample.foo.ServiceBundleFoo#foo-rpc, audit message: ...
Si les ACL et les autorisations échouent, une erreur est consignée pour les deux :
E SdvServiceManagerServer: Authz violation. com.sdv.google.sample.foo.ServiceBundleFoo#foo-rpc denies access to instance2:com.sdv.google.sample.bar.ServiceBundleBar/instance, audit message: ...
E SdvServiceManagerServer: Authz violation. instance2:com.sdv.google.sample.bar.ServiceBundleBar/instance does not declare permission to access com.sdv.google.sample.foo.ServiceBundleFoo#foo-rpc, audit message: ...
Mode strict
En mode Strict, les LCA et les autorisations doivent autoriser l'accès. Si les ACL ou les autorisations échouent, l'accès est refusé et une erreur est consignée.