Política de autorização no nível da VM

As permissões no nível da VM definem políticas de autorização para comunicação entre diferentes VMs na rede de malha do veículo definido por software (SDV, na sigla em inglês). Elas oferecem segurança de defesa em profundidade caso uma VM seja comprometida.

É necessário conceder permissões no nível do serviço e da VM para permitir a comunicação entre VMs.

Esquema proto

As permissões no nível da VM são definidas usando uma única mensagem VmAuthzPolicy no formato textproto.

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;
}

Decisão de autorização

A avaliação segue uma ordem de precedência estrita, em que a negação substitui a permissão na mesma granularidade. Por padrão, toda a comunicação entre VMs é negada.

Ordem de avaliação de precedência

A lógica de decisão verifica as permissões na seguinte ordem:

  1. Negação granular: se uma instância específica (mensagem + tópico ou serviço + canal) corresponder a uma regra deny_, ela será negada explicitamente.
  2. Permissão granular: se uma instância específica corresponder a uma regra allow_, ela será permitida.
  3. Negação de tipo: se um tipo de mensagem ou interface de serviço corresponder a uma regra deny_ (topic: "*" ou channel: "*"), ela será negada explicitamente.
  4. Permissão de tipo: se um tipo de mensagem ou interface de serviço corresponder a uma regra allow_ (topic: "*" ou channel: "*"), ela será permitida.
  5. Negação geral: se todos os tipos de mensagem ou serviços forem negados (message: "*" ou service: "*"), ela será negada explicitamente.
  6. Permissão geral: se todos os tipos de mensagem ou serviços forem permitidos (message: "*" ou service: "*"), ela será permitida.
  7. Padrão implícito: se nenhuma regra corresponder, ela será negada implicitamente. O padrão do sistema é negar tudo.

Exemplos

Os exemplos a seguir demonstram como a política de autorização é avaliada.

A permissão granular substitui a negação de tipo

# 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"
}

A negação de tipo substitui a permissão geral

# 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: "*"
}