Deployment

Authorization policy file deployment defines the designated storage location for the policy file specific to each software-defined vehicle (SDV) service. The deployment mechanism varies between SDV core and SDV IVI platforms.

SDV core platform

The SDV core platform uses APEX files for packaging service bundles and service bundles configuration. The service bundles registry component retrieves the authorization policy for SDV service bundles stored in APEXes.

APEX is a signed package with a unique name called a package name. Each APEX can contain multiple service bundles. Each service bundle has its metadata declared in the manifest file in the APEX.

Service bundle metadata has a path to the authorization policy file, which should be located within the same APEX.

Deploy the authorization policy for the SDV service with the identity {sdv-vm-name}:{package.name}.{ServiceBundle}.{instance-name} on SDV as follows:

  1. Put the authorization policy file in the package.name APEX.
  2. Update the ServiceBundle entry in the service bundles manifest file in the package.name APEX by adding the corresponding authorization policy path into the authorization_policy_path field.
  3. Deploy the package.name APEX into the sdv-vm-name VM.

Example

(apex_root) sdv_service_bundles_manifest.textproto

sdv_service_bundle_metadata {
  name: "SampleRpcServer"
  version_number: 0
  version_name: "0.1 Alpha"
  native_library_path: "lib64/libsdv_sample_rpc.so"
  # Path to the authorization policy file.
  # Warning: Must be a relative path to the APEX root directory.
  authorization_policy_path: "etc/authz/sample_rpc/permissions.textproto"
}

Place the authorization policy file in etc/authz/sample_rpc/permissions.textproto within the same APEX where sdv_service_bundles_manifest.textproto is located.

SDV IVI platform

There are certain differences between the SDV IVI platform and the SDV core implementations. In the SDV IVI platform:

  • There is no service bundle registry.
  • Apps are Java based and they are delivered in APKs.
  • Agents aren't in APEXes.

Because of these factors, deployment on the SDV platform is different.

Deploy the authorization policy for the SDV service with the identity {ivi-vm-name}:{package.name}.{ServiceBundle}/{instance-name} on SDV IVI as follows:

  1. Define the authorization policy path according to the {policy-dir}/{package.name}/{ServiceBundle}.textproto pattern.
    • Where policy-dir is one of the following:
      • /product/etc/sdv_authz_policies
      • /system/etc/sdv_authz_policies
      • /system_ext/etc/sdv_authz_policies
      • /vendor/etc/sdv_authz_policies
    • For example, /vendor/etc/sdv_authz_policies/com.sdv.pkg/WindowManager.textproto is a valid authorization policy path.
  2. Put the authorization policy in the authorization policy path on the ivi-vm-name VM.

Agents and test support

SDV agents have the same authorization policy deployment on both SDV core and SDV IVI. If an agent doesn't have an APEX, its corresponding authorization policy must be located in a companion config-only APEX.

Example

(apex_root) sdv_service_bundles_manifest.textproto

sdv_service_bundle_metadata {
   # Should match the bundle name in the FQIN registered by the SOME/IP broker agent
   name: "SomeIpBroker"
   # Version number of the config APEX
   version_number: 1
   # Version name of the config APEX
   version_name: "1"

   # Reference the manifest itself to mark the metadata as a config-only
   # declaration.
   native_library_path: "etc/sdv_service_bundles_manifest.textproto"

   # Path to the authorization policy file for SOME/IP broker.
   authorization_policy_path: "etc/config/access_control/someip_authz_policy.textproto"
}

VM-level authorization policy

Put VM-level policies in the APEX with package name com.oem.sdv.authz. Use a dedicated file with the corresponding <vm_name>.textproto name.

If the corresponding <vm_name>.textproto doesn't exist, the authorization framework also looks for a .default.textproto file in the same APEX.

Rationale

The .default.textproto is introduced for two reasons:

  • Simplified setup: For some OEMs, it might be sufficient to set default.textproto for all SDV VMs, and only provide a special <vm-name>.textproto for the IVI VM.
  • Updatability: If a new VM appears after a vehicle update, a reasonable default.textproto might be sufficient to avoid updating all VMs.

Resolution logic

When checking permissions for a subject from a VM called <vm-name>, the authorization framework looks for policies in the following order:

  1. <vm-name>.textproto: If it exists, perform the check based on it. If it doesn't exist, fall back to the default file.
  2. .default.textproto: If it exists, perform the check based on it. If it doesn't exist, deny access.

Define the Soong module with VM-level permissions

The module must be an APEX with package name com.oem.sdv.authz.

Add the value to the .mk file:

SDV_VM_LEVEL_PERMISSIONS_MODULE := {soong.module.name}