Debug permissions violations

An authorization violation occurs when a service attempts to perform an action that it isn't permitted to execute. In the standard permissionsOnly enforcement mode, the Software-Defined Vehicle (SDV) framework checks if the subject or its virtual machine (VM) has the required permission declared in its policy.

You must evaluate violation messages within their security context. Not every violation indicates an error or an attempt at unauthorized access.

All authorization decisions are logged. To view them, search the logcat output for audit messages:

adb -s $SERIAL logcat | grep 'audit message'

Successful authorization

Successful checks are logged at the debug level.

This indicates that the subject has the required permission declared:

D SdvServiceManagerServer: instance2:com.sdv.google.sample.bar.ServiceBundleBar/instance declares permission to access com.sdv.google.sample.foo.ServiceBundleFoo#foo-rpc, audit message: ...

Violations and permissions missing

Violations occur when a permission is missing.

This occurs when the subject lacks the necessary permission, such as client, server, publisher, or subscriber, in its authorization policy, or the subject's VM lacks it in the VM-level policy.

This is logged at the error level:

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...

Remediation

The log's audit message often contains a useful suggestion on what needs to be added to resolve a violation.

For example, you might see a permission error like this:

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

Remediate this by adding the rule to the subject's authorization policy textproto:

client {
    service: "com.server.TargetType"
    channel: "my-unit"
}

If the error message indicates a missing permission in the subject's VM, you must add it to the VM-level policy, such as <vm_name>.textproto or .default.textproto in the com.oem.sdv.authz APEX:

allow_server {
    service: "com.server.TargetType"
    channel: "my-unit"
}

Migrate from ACLs

For backward compatibility and migration, the framework supports ACLs only, Lenient, and Strict modes that consider earlier access control lists (ACLs).

ACLs only mode

In ACLs only mode, access is allowed only if ACLs allow it. Permissions are ignored. If ACLs deny access, an error is logged:

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: ...

Lenient mode

In Lenient mode, access is allowed if either ACLs or permissions allow it. If access is granted using ACLs but permissions are missing, it is logged as a soft violation at the debug level to help you identify missing permissions while keeping the system functional:

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: ...

If both ACLs and permissions fail, it's logged as an error for both:

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: ...

Strict mode

In Strict mode, both ACLs and permissions must allow access. If either ACLs or permissions fail, access is denied and an error is logged.