[[435507]]

想了解更多內容，請訪問：

51CTO和華為官方合作共建的鴻蒙技術社區

https://harmonyos.51cto.com

1.簡介

安全子系統為OpenHarmony提供有效保護應用和用戶數據的能力。

主要功能： 系統安全、數據安全、應用安全等;

目前開源功能： 應用完整性保護、應用權限管理、設備認證、密鑰管理服務、數據分級保護;

應用權限管理： 為程序框架子系統提供權限管理功能，并且為上層應用提供權限申請和授權狀態查詢接口。

本文將介紹標準系統下安全子系統應用權限管理部分如何在系統內適配及實現，盡力深入細節部分。

1.1 OpenHarmony 架構圖

1.2 安全子系統

1.3 應用權限管理

OpenHarmony中應用和系統服務均運行在獨立的沙箱中，進程空間和程序數據都是相互隔離的，以保護應用數據的安全性;但是運行在獨立沙箱中的服務或應用同時需要對外提供一些API以實現所需功能，其他獨立沙箱中的應用在跨進程訪問這些API時，需要系統提供一種權限管理機制對這些API的訪問者進行授權。

應用權限管理提供了權限定義機制，允許系統服務和應用為自己的敏感API定義新的權限，其他應用必須申請此權限才能訪問此敏感API;

應用權限管理提供了權限申請機制，允許應用申請權限，這些權限由系統或者其他應用定義，權限申請通過后就能訪問這個權限相關的系統或其他應用提供的敏感API;

應用權限管理也為用戶提供了一些必須的功能，方便用戶查看和管理權限授予情況。

2.基礎知識

2.1 代碼結構

/base/security/permission 
├── frameworks # 基礎設施層 
│ └── permission_standard # 標準系統權限管理基礎設施層 
├── interfaces # 接口層 
│ ├── innerkits # 內部接口層 
│ │ ├── permission_lite # 輕量系統、小型系統權限管理內部接口層 
│ │ └── permission_standard # 標準系統權限管理內部接口層 
│ └── kits # 外部接口層 
│ ├── permission_lite # 輕量系統、小型系統權限管理外部接口層 
│ └── permission_standard # 標準系統權限管理外部接口層 
└── services # 服務層 
├── permission_lite # 輕量系統、小型系統權限管理服務層 
└── permission_standard # 標準系統權限管理服務層 

2.2 SystemAbility

應用權限管理模塊是以SystemAbility的形式對外提供能力的，在分布式任務調度子系統中safwk組件定義OpenHarmony中SystemAbility的實現方法，并提供啟動、注冊等接口實現。

實現一個SystemAbility需要六個步驟：

1)定義該服務對外提供的能力集合函數

namespace OHOS { 
class IListenAbility : public IRemoteBroker { 
public: 
    virtual int AddVolume(int volume) = 0; 
 
public: 
    enum { 
        ADD_VOLUME = 1, 
    }; 
public: 
    DECLARE_INTERFACE_DESCRIPTOR(u"OHOS.test.IListenAbility"); 
}; 
} 

 2) 定義客戶端通信代碼XXXProxy

namespace OHOS { 
class ListenAbilityProxy : public IRemoteProxy<IListenAbility> { 
public: 
    int AddVolume(int volume); 
 
    explicit ListenAbilityProxy(const sptr<IRemoteObject>& impl) 
        : IRemoteProxy<IListenAbility>(impl) 
    { 
    } 
 
private: 
    static inline BrokerDelegator<ListenAbilityProxy> delegator_; 
}; 
} // namespace OHOS 

 3) 定義服務端通信代碼XXXStub

namespace OHOS { 
int32_t ListenAbilityStub::OnRemoteRequest(uint32_t code, 
    MessageParcel& data, MessageParcel &reply, MessageOption &option) 
{ 
    switch (code) { 
        case ADD_VOLUME: { 
            return reply.WriteInt32(AddVolume(data.ReadInt32())); 
        } 
        default: 
            return IPCObjectStub::OnRemoteRequest(code, data, reply, option); 
    } 
} 
} 

 4)SystemAbility的實現類 

namespace { 
constexpr OHOS::HiviewDFX::HiLogLabel LABEL = {LOG_CORE, 0xD001800, "SA_TST"}; 
} 
 
REGISTER_SYSTEM_ABILITY_BY_ID(ListenAbility, DISTRIBUTED_SCHED_TEST_LISTEN_ID, true); 
 
ListenAbility::ListenAbility(int32_t saId, bool runOnCreate) : SystemAbility(saId, runOnCreate) 
{ 
    HiLog::Info(LABEL, ":%s called", __func__); 
    HiLog::Info(LABEL, "ListenAbility()"); 
} 
 
ListenAbility::~ListenAbility() 
{ 
    HiLog::Info(LABEL, "~ListenAbility()"); 
} 
 
int ListenAbility::AddVolume(int volume) 
{ 
    pid_t current = getpid(); 
    HiLog::Info(LABEL, "ListenAbility::AddVolume volume = %d, pid = %d.", volume, current); 
    return (volume + 1); 
} 
 
void ListenAbility::OnDump() 
{ 
} 
 
void ListenAbility::OnStart() 
{ 
    HiLog::Info(LABEL, "ListenAbility::OnStart()"); 
    HiLog::Info(LABEL, "ListenAbility:%s called:-----Publish------", __func__); 
    bool res = Publish(this); 
    if (res) { 
        HiLog::Error(LABEL, "ListenAbility: res == false"); 
    } 
    HiLog::Info(LABEL, "ListenAbility:%s called:AddAbilityListener_OS_TST----beg-----", __func__); 
    AddSystemAbilityListener(DISTRIBUTED_SCHED_TEST_OS_ID); 
    HiLog::Info(LABEL, "ListenAbility:%s called:AddAbilityListener_OS_TST----end-----", __func__); 
 
    HiLog::Info(LABEL, "ListenAbility:%s called:StopAbility_OS_TST----beg-----", __func__); 
    StopAbility(DISTRIBUTED_SCHED_TEST_OS_ID); 
    HiLog::Info(LABEL, "ListenAbility:%s called:StopAbility_OS_TST----end-----", __func__); 
    return; 
} 
 
void ListenAbility::OnStop() 
{ 

5)SystemAbility配置

以c++實現的SA必須配置相關System Ability的profile配置文件才會完成SA的加載注冊邏輯，否則沒有編寫profile配置的System Ability不會完成注冊。配置方法如下：

在子系統的根目錄新建一個以sa_profile為名的文件夾;然后在此文件夾中新建兩個文件：一個以serviceId為前綴的xml文件;另外一個為BUILD.gn文件

<?xml version="1.0" encoding="UTF-8"?> 
<info> 
    <process>listen_test</process> 
    <systemability> 
    <name>serviceid</name> 
    <libpath>/system/lib64/liblistentest.z.so</libpath> 
    <run-on-create>true</run-on-create> 
    <distributed>false</distributed> 
    <dump-level>1</dump-level> 
</systemability> 
</info> 

 BUILD.gn：

import("//build/ohos/sa_profile/sa_profile.gni") 
ohos_sa_profile("xxx_sa_profile") { 
    sources = [ 
        "serviceid.xml" 
    ] 
    subsystem_name = "distributedschedule" 
} 

6)rc配置文件

rc配置文件為linux提供的native進程拉起策略，為手機在開機啟動階段由init進程解析配置的rc文件進行拉起

service listen_test /system/bin/sa_main /system/profile/listen_test.xml 
    class z_core 
    user system 
    group system shell 
    seclabel u:r:xxxx:s0 

2.3 接口說明

標準系統用戶程序框架子系統提供權限管理基礎校驗能力，不對三方app開放，并提供如下API。

3.內部實現

3.1 類間關系

IPermissionManager：內部接口類

PermissionManagerProxy：IPC請求的代理類

PermissionManagerStub：IPC請求服務類

PermissionManagerClient：應用權限管理客戶類

PermissionKit：組件對外接口類,真正對外提供STATIC接口函數

PermissionManagerService：應用權限功能服務類，調用PermissionStateManager和PermissionDefinitionManager

PermissionStateManager：真正的應用權限管理功能實現

PermissionDefinitionManager：真正的應用權限管理功能實現

3.2 內部邏輯

標準系統下應用權限管理功能是基于SAMgr管理框架實現，如何配置SAMgr框架見基礎知識介紹，如果想學習更多細節參見SAMgr相關學習，這里專注于應用權限管理功能部分，并對代碼邏輯關鍵節點進行分析和展示。

應用權限管理組件通過PermissionKit類以單例模式對外提供接口，PermissionKit類內部接口函數則調用PermissionManagerClient類，PermissionManagerClient則通過調用GetSystemAbility函數獲取向SAMgr注冊過的代理類單例PermissionManagerProxy。

代碼如下：

sptr<IPermissionManager> PermissionManagerClient::GetProxy() const 
{ 
    auto sam = SystemAbilityManagerClient::GetInstance().GetSystemAbilityManager(); 
    if (sam == nullptr) { 
        PERMISSION_LOG_DEBUG(LABEL, "%{public}s: GetSystemAbilityManager is null", __func__); 
        return nullptr; 
    } 
    // 獲取Proxy 
    auto permissionSa = sam->GetSystemAbility(IPermissionManager::SA_ID_PERMISSION_MANAGER_SERVICE); 
    if (permissionSa == nullptr) { 
        PERMISSION_LOG_DEBUG(LABEL, "%{public}s: GetSystemAbility %{public}d is null", __func__, 
            IPermissionManager::SA_ID_PERMISSION_MANAGER_SERVICE); 
        return nullptr; 
    } 
 
    auto proxy = iface_cast<IPermissionManager>(permissionSa); 
    if (proxy == nullptr) { 
        PERMISSION_LOG_DEBUG(LABEL, "%{public}s: iface_cast get null", __func__); 
        return nullptr; 
    } 
    return proxy; 
} 

 在獲取代理類PermissionManagerProxy后，PermissionManagerProxy內部不同功能接口函數會調用SendRequest函數發起IPC請求服務。

示例代碼如下(刪去省略部分)：

int PermissionManagerProxy::VerifyPermission( 
    const std::string& bundleName, const std::string& permissionName, int userId) 
{ 
    // 省略部分 
    ..................... 
    // 發送請求服務 
    int32_t requestResult = remote->SendRequest( 
        static_cast<uint32_t>(IPermissionManager::InterfaceCode::VERIFY_PERMISSION), data, reply, option); 
    if (requestResult != NO_ERROR) { 
        PERMISSION_LOG_ERROR(LABEL, "%{public}s send request fail, result: %{public}d", __func__, requestResult); 
        return PERMISSION_NOT_GRANTED; 
    } 
 
    int32_t result = reply.ReadInt32(); 
    PERMISSION_LOG_DEBUG(LABEL, "%{public}s get result from server data = %{public}d", __func__, result); 
    return result; 
} 

 其中接口類IPermissionManager中定義了IPC通信的請求碼。

示例代碼如下(刪去省略部分)：

class IPermissionManager : public IRemoteBroker { 
public: 
    static const int SA_ID_PERMISSION_MANAGER_SERVICE = 3501; 
 
    DECLARE_INTERFACE_DESCRIPTOR(u"ohos.security.permission.IPermissionManager"); 
 
    virtual int VerifyPermission(const std::string& bundleName, const std::string& permissionName, int userId) = 0; 
    // 省略部分 
    ................................ 
    // 請求碼 
    enum class InterfaceCode { 
        VERIFY_PERMISSION = 0xff01, 
        CAN_REQUEST_PERMISSION = 0xff02, 
        GRANT_USER_GRANTED_PERMISSION = 0xff03, 
        GRANT_SYSTEM_GRANTED_PERMISSION = 0xff04, 
        REVOKE_USER_GRANTED_PERMISSION = 0xff05, 
        REVOKE_SYSTEM_GRANTED_PERMISSION = 0xff06, 
        ADD_USER_GRANTED_REQ_PERMISSIONS = 0xff07, 
        ADD_SYSTEM_GRANTED_REQ_PERMISSIONS = 0xff08, 
        REMOVE_USER_GRANTED_REQ_PERMISSIONS = 0xff09, 
        REMOVE_SYSTEM_GRANTED_REQ_PERMISSIONS = 0xff10, 
        ADD_DEF_PERMISSIONS = 0xff11, 
        REMOVE_DEF_PERMISSIONS = 0xff12, 
        GET_DEF_PERMISSION = 0xff13, 
    }; 
}; 

PermissionManagerService類則由于繼承了PermissionManagerStub，會在接口函數OnRemoteRequest函數接收到代理PermissionManagerProxy通過IPC通信發送的不同請求，進而進行處理。

示例代碼如下：

int32_t PermissionManagerStub::OnRemoteRequest( 
    uint32_t code, MessageParcel& data, MessageParcel& reply, MessageOption& option) 
{ 
    PERMISSION_LOG_INFO(LABEL, "%{public}s called, code: %{public}d", __func__, code); 
    std::u16string descriptor = data.ReadInterfaceToken(); 
    if (descriptor != IPermissionManager::GetDescriptor()) { 
        PERMISSION_LOG_ERROR(LABEL, "get unexpect descriptor: %{public}s", Str16ToStr8(descriptor).c_str()); 
        return RET_FAILED; 
    } 
    switch (code) { 
        case static_cast<uint32_t>(IPermissionManager::InterfaceCode::VERIFY_PERMISSION): 
            VerifyPermissionInner(data, reply); 
            break; 
        case static_cast<uint32_t>(IPermissionManager::InterfaceCode::CAN_REQUEST_PERMISSION): 
            CanRequestPermissionInner(data, reply); 
            break; 
        case static_cast<uint32_t>(IPermissionManager::InterfaceCode::GRANT_USER_GRANTED_PERMISSION): 
            GrantUserGrantedPermissionInner(data, reply); 
            break; 
        // 省略部分 
        ....... 
 
        default: 
            return IPCObjectStub::OnRemoteRequest(code, data, reply, option); 
    } 
    return NO_ERROR; 
} 

最終PermissionManagerService則調用PermissionStateManager和PermissionDefinitionManager類所提供的函數做具體的功能實現。

4.總結

當今設備安全問題已經越來越引起不同行業的重視，OpenHarmney安全子系統作為系統基礎能力之一對開發設備的安全性尤為重要，對系統框架開發來說很有必要學習其內部原理并對代碼結構深入了解，本文檔拋磚引玉介紹了標準系統下應用權限管理的相關邏輯框架，后續隨著學習的深入將不斷完善對安全子系統的解讀。

想了解更多內容，請訪問：

51CTO和華為官方合作共建的鴻蒙技術社區

https://harmonyos.51cto.com