VM-level authorization policy

VM-level permissions define authorization policies for communication between different VMs in the Software-Defined Vehicle (SDV) mesh network. They provide defense-in-depth security in case one VM is compromised.

You must grant both service-level and VM-level permissions to permit cross-VM communication.

Proto schema

VM-level permissions are defined using a single VmAuthzPolicy message in textproto format.

message VmAuthzPolicy {
  repeated Publisher allow_publisher = 1;
  repeated Publisher deny_publisher = 2;
  repeated Subscriber allow_subscriber = 3;
  repeated Subscriber deny_subscriber = 4;
  repeated Server allow_server = 5;
  repeated Server deny_server = 6;
  repeated Client allow_client = 7;
  repeated Client deny_client = 8;
}

// Reuses the same Publisher message from AuthzPolicy, but uses "*" for
// wildcards.
message Publisher {
  string message = 1;
  repeated string topic = 2;
}

// Reuses the same Subscriber message from AuthzPolicy, but uses "*" for
// wildcards.
message Subscriber {
  string message = 1;
  repeated string topic = 2;
}

// Reuses the same Server message from AuthzPolicy, but uses "*" for
// wildcards.
message Server {
  string service = 1;
  repeated string channel = 2;
}

// Reuses the same Client message from AuthzPolicy, but uses "*" for
// wildcards.
message Client {
  string service = 1;
  repeated string channel = 2;
}

Authorization decision

Evaluation follows a strict precedence order, where Deny overrides Allow at the same granularity. By default, all cross-VM communication is denied.

Precedence evaluation order

The decision logic checks permissions in the following order:

  1. Granular Deny: If a specific instance (Message+Topic or Service+Channel) matches a deny_ rule, it is Explicitly denied.
  2. Granular Allow: If a specific instance matches an allow_ rule, it is Permitted.
  3. Type Deny: If a whole Message type or Service interface matches a deny_ rule (topic: "*" or channel: "*"), it is Explicitly denied.
  4. Type Allow: If a whole Message type or Service interface matches an allow_ rule (topic: "*" or channel: "*"), it is Permitted.
  5. Blanket Deny: If all message types or services are denied (message: "*" or service: "*"), it is Explicitly denied.
  6. Blanket Allow: If all message types or services are allowed (message: "*" or service: "*"), it is Permitted.
  7. Implicit Default: If no rule matches, it is Implicitly denied. The system default is to deny all.

Examples

The following examples demonstrate how the authorization policy is evaluated.

Granular allow overrides type deny

# Deny door unlock publications by default...
deny_publisher {
  message: "com.sdv.security.UnlockDoors"
  topic: "*"
}

# ...but allow it for the driver door.
allow_publisher {
  message: "com.sdv.security.UnlockDoors"
  topic: "driver_door"
}

Type deny overrides blanket allow

# Allow all client calls globally (blanket allow)...
allow_client {
  service: "*"
  channel: "*"
}

# ...except for the firmware update service (system-wide deny).
deny_client {
  service: "com.sdv.diagnostic.FirmwareUpdate"
  channel: "*"
}