Управление разрешениями приложений

Введение

В OpenHarmony приложения и системные службы выполняются в независимых песочницах. Процессы и данные изолированы друг от друга для защиты безопасности данных приложений. Однако службы или приложения, выполняющиеся в песочницах, предоставляют некоторые API для реализации конкретных функциональностей. Для доступа к этим API через процессы приложениям в других песочницах требуются соответствующие разрешения, которые выдаются и управляются на основе механизма управления разрешениями.

Управление разрешениями приложений предоставляет следующие возможности:

• Предоставляет механизм для определения разрешений, позволяющий системным службам и приложениям определять новые разрешения для своих чувствительных API. Для доступа к этим API другим приложениям требуются соответствующие разрешения.

• Позволяет приложениям запрашивать разрешения, определенные системой или другими приложениями. После получения разрешений приложения могут получить доступ к чувствительным API, предоставляемым системой или другими приложениями.

• Позволяет пользователям просматривать и управлять статусом выдачи разрешений.

Рис. 1 Архитектура управления разрешениями приложений

Управление разрешениями приложений предоставляет управление разрешениями для подсистемы фреймворка приложений и предоставляет API для приложений для запроса разрешений и проверки статуса выдачи разрешений. Открытая система управления разрешениями приложений применима к мини- и малым системам.

• Мини-система предназначена для устройств с памятью, размер которой составляет 128 КБ или более, и оборудованных процессорами MCU, такими как ARM Cortex-M и 32-битными RISC-V. Она предоставляет различные легковесные сетевые протоколы, легковесные графические фреймворки и компоненты чтения/записи IoT через шину. Мини-система применима к продуктам умного дома, таким как модули LinkIoT, датчики и носимые устройства.

• Малая система ориентирована на устройства с памятью, размер которой составляет 1 МБ или более, и оборудованных процессорами, такими как ARM Cortex-A. Она предоставляет более высокие возможности безопасности, стандартные графические фреймворки и кодирование/декодирование видео. Малая система применима к продуктам умного дома, таким как IP-камеры, видеодверные глаза и маршрутизаторы, а также к продуктам умного путешествия, так как устройства записи событий (EDRs).## Структура каталогов

/base/безопасность/разрешения_лайт
├── интерфейсы                        # API
│   ├── внутренние_киты                # Внутренние API
│   └── киты                          # Внешние API
└── сервисы                           # Сервисы
    ├── ipc_автентификация            # Аутентификация IPC-коммуникации
    ├── js_апи                        # Упаковка JS API
    ├── пмс                           # Логика управления разрешениями и сервер
    ├── пмс_база                     # Регистрация сервисов
    └── пмс_клиент                    # Клиент управления разрешениями

Использование### Доступные API

API для управления разрешениями приложений в мини- и малых системах могут быть вызваны только системными приложениями и службами. Ниже приведена таблица, описывающая эти API.

Ниже приведена таблица, описывающая API для аутентификации IPC в мини- и малых системах.| API | Описание | | ------------------------------------------------------------ | ------------------------------------------------------------ | | int GetCommunicationStrategy(RegParams params, PolicyTrans **policies, unsigned int *policyNum) | Получает политики доступа для API службы. Этот API может быть вызван только службой управления способностями системы (SAMGR). | | int IsCommunicationAllowed(AuthParams params) | Проверяет, имеет ли процесс разрешение на доступ к API другого процесса. Этот API может быть вызван только SAMGR. |

Как использовать

Управление разрешениями приложения для мини- или малых системВ качестве примера используется разработка разрешений приложения в службе управления пакетами (BMS). В файле config.json необходимо объявить требуемые чувствительные разрешения во время разработки. В процессе установки приложения BMS вызывает API-интерфейсы компонента управления разрешениями приложения для проверки наличия требуемых разрешений. Если разрешения доступны, установка продолжается; в противном случае установка завершается неудачей. 1. Во время разработки определите и объявите необходимое разрешение (ohos.permission.INSTALL_BUNDLE) для установки приложения. Если используется модель FA, объявите разрешение в файле config.json. Пример представлен ниже: json { "module": { "package": "ohos.demo.kitframework", "deviceType": [ "phone", "tv", "tablet", "car", "smartWatch", "sportsWatch", "smartCamera", "smartVision" ], "reqPermissions": [{ "name": "ohos.permission.INSTALL_BUNDLE", "reason": "установка пакета", "usedScene": { "ability": [ "KitFramework" ], "when": "always" } }, { "name": "ohos.permission.LISTEN_BUNDLE_CHANGE", "reason": "установка пакета", "usedScene": { "ability": [ "KitFramework" ], "when": "always" } }, { "name": "ohos.permission.GET_BUNDLE_INFO", "reason": "установка пакета", "usedScene": { "ability": [ "KitFramework" ], "when": "always" } } ] } } Если используется модель Stage, объявите разрешение в файле module.json5. Пример представлен ниже: json { "module": { "requestPermissions": [{ "name": "ohos.permission.INSTALL_BUNDLE", "reason": "установка пакета", "usedScene": { "ability": [ "KitFramework" ], "when": "always" } }, { "name": "ohos.permission.LISTEN_BUNDLE_CHANGE", "reason": "установка пакета", "usedScene": { "ability": [ "KitFramework" ], "when": "always" } }, { "name": "ohos.permission.GET_BUNDLE_INFO", "reason": "установка пакета", "usedScene": { "ability": [ "KitFramework" ], "when": "always" } }] } }

2. При разработке API для установки приложения используйте API CheckPermission() для проверки наличия у BMS (Bundle Management System) разрешения на установку приложения. Например, CheckPermission() вызывается с именем разрешения ohos.permission.INSTALL_BUNDLE в качестве входного параметра для проверки наличия у BMS разрешения на установку приложения. Если у BMS есть разрешение, процесс установки продолжается. В противном случае установка завершается неудачей. ```c++ constexpr static char PERMISSION_INSTALL_BUNDLE[] = "ohos.permission.INSTALL_BUNDLE";

   bool Install(const char *hapPath, const InstallParam *installParam, InstallerCallback installerCallback) { if ((hapPath == nullptr) || (installerCallback == nullptr) || (installParam == nullptr)) { HILOG_ERROR(HILOG_MODULE_APP, "BundleManager install failed due to nullptr parameters"); return false; } // Проверка наличия разрешения ohos.permission.INSTALL_BUNDLE. if (CheckPermission(0, static_cast<const char *>(PERMISSION_INSTALL_BUNDLE)) != GRANTED) { HILOG_ERROR(HILOG_MODULE_APP, "BundleManager install failed due to permission denied"); return false; // Установка приложения не удалась. } // Процесс установки. ... }

IPC аутентификация для мини- или малых систем

В следующем примере описывается, как использовать компонент аутентификации IPC для настройки политик доступа к функциям BMS. В этом примере сервис, зарегистрированный BMS в SAMGR, имеет имя bundlems, а зарегистрированная функция имеет имя BmsFeature.

1. Настройте политику доступа в заголовочном файле base/security/permission_lite/services/ipc_auth/include/policy_preset.h в директории исходного кода. Существует три типа политик доступа: - RANGE: разрешает доступ из процессов с UIDs в указанном диапазоне. uidMin и uidMax должны быть указаны.

   • FIXED: разрешает доступ из процессов с указанными UIDs. fixedUid должен быть указан, и допускается максимум восемь UIDs.
   • BUNDLENAME: разрешает доступ из указанного приложения. bundleName должен быть указан.

   FeaturePolicy bmsFeature[] = {
       {
           "BmsFeature",
           {
               {
                   .type=FIXED,    // Разрешить доступ из процессов с указанными UIDs.
                   .fixedUid={2, 3, 8}
               },
               {
                   .type=RANGE,    // Разрешить доступ из процессов с UIDs в указанном диапазоне.
                   .uidMin=100,
                   .uidMax=__INT_MAX__,
               },
           }
       },
       {
           "BmsInnerFeature",
           {
               {
                   .type=FIXED,    // Разрешить доступ из процессов с указанными UIDs.
                   .fixedUid={2, 3, 8}
               },
               {
                   .type=RANGE,
                   .uidMin=100,
                   .uidMax=999,
               },
           }
       },
   };
   ```2. Добавьте политики, настроенные для функций из шага 1, в глобальные параметры политики. Вам нужно установить количество функций.    ```c++
   static PolicySetting g_presetPolicies[] = {
       {"permissionms", pmsFeature, 1},
       {"abilityms", amsFeature, 2},
       {"bundlems", bmsFeature, 2}, // Функция BMS, определенная в шаге 1. Количество функций BMS равно 2.
       {"dtbschedsrv", dmsFeature, 1},
       {"samgr", samgrFeature, 1},
       {"appspawn", appspawnFeature, 1},
       {"WMS", wmsFeature, 1},
       {"bundle_daemon", bdsFeature, 1},
   };

2. Зарегистрируйте BmsFeature, определенный в шаге 1, с SAMGR.

   const char BMS_SERVICE[] = "bundlems";
   const char BMS_FEATURE[] = "BmsFeature";
   static void Init()
   {
       SamgrLite *sm = SAMGR_GetInstance();
       if (sm == nullptr) {
           return;
       }
       // Регистрация сервиса с SAMGR.
       sm->RegisterFeature(BMS_SERVICE, reinterpret_cast<Feature *>(BundleMsFeature::GetInstance()));
       sm->RegisterFeatureApi(BMS_SERVICE, BMS_FEATURE,
           GetBmsFeatureApi(reinterpret_cast<Feature *>(BundleMsFeature::GetInstance())));
       HILOG_DEBUG(HILOG_MODULE_APP, "Успешное начало функции BundleMS");
   }
   APP_FEATURE_INIT(Init);

Когда указанные сервисы регистрируются с SAMGR, SAMGR вызывает метод GetCommunicationStrategy() компонента аутентификации IPC для получения политики доступа для сервисов. Когда другие сервисы или приложения обращаются к этим сервисам через IPC, SAMGR вызывает метод IsCommunicationAllowed() компонента аутентификации IPC для проверки разрешений вызывающего сервиса. Если политика доступа удовлетворена, доступ разрешается. В противном случае доступ отклоняется.

Вовлеченные репозитории

Подсистема безопасности

security_permission_lite