デプロイ

認可ポリシー ファイルのデプロイでは、各ソフトウェア定義車両（SDV）サービスに固有のポリシー ファイルの指定された保存場所を定義します。デプロイ メカニズムは、SDV コア プラットフォームと SDV IVI プラットフォームで異なります。

SDV コア プラットフォーム

SDV コア プラットフォームは、サービス バンドルとサービス バンドル構成のパッケージ化に APEX ファイルを使用します。サービス バンドル レジストリ コンポーネントは、APEX に保存されている SDV サービス バンドルの認可ポリシーを取得します。

APEX は、パッケージ名と呼ばれる一意の名前を持つ署名付きパッケージです。各 APEX には複数のサービス バンドルを含めることができます。各サービス バンドルには、APEX のマニフェスト ファイルで宣言されたメタデータがあります。

サービス バンドル メタデータには、同じ APEX 内にある認証ポリシー ファイルへのパスがあります。

SDV サービスに ID {sdv-vm-name}:{package.name}.{ServiceBundle}.{instance-name} を使用して、次のように認可ポリシーをデプロイします。

  1. 認可ポリシー ファイルを package.name APEX に配置します。
  2. package.name APEX のサービス バンドル マニフェスト ファイルの ServiceBundle エントリを更新して、対応する認可ポリシーのパスを authorization_policy_path フィールドに追加します。
  3. package.name APEX を sdv-vm-name VM にデプロイします。

例

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

認可ポリシー ファイルを、sdv_service_bundles_manifest.textproto が配置されているのと同じ APEX 内の etc/authz/sample_rpc/permissions.textproto に配置します。

SDV IVI プラットフォーム

SDV IVI プラットフォームと SDV コア実装にはいくつかの違いがあります。SDV IVI プラットフォームの場合:

  • サービス バンドル レジストリがありません。
  • アプリは Java ベースで、APK で配信されます。
  • エージェントは APEX にありません。

これらの要因により、SDV プラットフォームへのデプロイは異なります。

SDV IVI で、ID {ivi-vm-name}:{package.name}.{ServiceBundle}/{instance-name} を使用して SDV サービスの認可ポリシーを次のようにデプロイします。

  1. {policy-dir}/{package.name}/{ServiceBundle}.textproto パターンに従って、認可ポリシーのパスを定義します。
    • ここで、policy-dir は次のいずれかです。
      • /product/etc/sdv_authz_policies
      • /system/etc/sdv_authz_policies
      • /system_ext/etc/sdv_authz_policies
      • /vendor/etc/sdv_authz_policies
    • たとえば、/vendor/etc/sdv_authz_policies/com.sdv.pkg/WindowManager.textproto は有効な認可ポリシーのパスです。
  2. 認可ポリシーを ivi-vm-name VM の認可ポリシー パスに配置します。

エージェントとテストのサポート

SDV エージェントは、SDV コアと SDV IVI の両方に同じ認可ポリシーをデプロイします。エージェントに APEX がない場合、対応する認可ポリシーはコンパニオンの構成専用 APEX に配置する必要があります。

例

(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 レベルの認可ポリシー

パッケージ名 com.oem.sdv.authz の APEX に VM レベルのポリシーを配置します。対応する <vm_name>.textproto 名の専用ファイルを使用します。

対応する <vm_name>.textproto が存在しない場合、認可フレームワークは同じ APEX 内の .default.textproto ファイルも検索します。

根拠

.default.textproto が導入される理由は次の 2 つです。

  • セットアップの簡素化: 一部の OEM では、すべての SDV VM に default.textproto を設定し、IVI VM にのみ特別な <vm-name>.textproto を提供するだけで十分な場合があります。
  • 更新可能性: 車両の更新後に新しい VM が表示された場合、すべての VM の更新を回避するには、妥当な default.textproto で十分な場合があります。

解決ロジック

<vm-name> という VM からサブジェクトの権限を確認する場合、認可フレームワークは次の順序でポリシーを探します。

  1. <vm-name>.textproto: 存在する場合は、それに基づいてチェックを実行します。存在しない場合は、デフォルトのファイルにフォールバックします。
  2. .default.textproto: 存在する場合は、それに基づいてチェックを実行します。存在しない場合はアクセスを拒否します。

VM レベルの権限で Soong モジュールを定義する

モジュールは、パッケージ名 com.oem.sdv.authz の APEX でなければなりません。

値を .mk ファイルに追加します。

SDV_VM_LEVEL_PERMISSIONS_MODULE := {soong.module.name}