鸿蒙应用权限管理和访问控制

目录

鸿蒙系统权限主要解决两个方面的问题

一、应用和服务间权限管理

二、应用权限访问控制

三、访问控制开发

---

鸿蒙系统权限主要解决两个方面的问题

1.应用或服务进程间权限访问的管理

采用的是基于ATM的VerifyPermission所有接口均为内部接口仅提供底层能力不对开发者开放。鉴权过程中直接调用VerifyPermission接口即可。

2.访问控制列表ACL

ACLAccess Control List提供了解决低等级应用访问高等级权限问题的特殊渠道。采用的是应用APL(Ability Privilege Level)等级和授权方式授权分为system_grant系统授权和user_grant用户授权。

一、应用和服务间权限管理

OpenHarmony中应用和系统服务均运行在独立的沙箱中进程空间和程序数据都是相互隔离的以保护应用数据的安全性但是运行在独立沙箱中的服务或应用同时需要对外提供一些API以实现所需功能其他独立沙箱中的应用在跨进程访问这些API时需要系统提供一种权限管理机制对这些API的访问者进行授权。

1. 应用权限管理提供了权限定义机制允许系统服务和应用为自己的敏感API定义新的权限其他应用必须申请此权限才能访问此敏感API
2. 应用权限管理提供了权限申请机制允许应用申请权限这些权限由系统或者其他应用定义权限申请通过后就能访问这个权限相关的系统或其他应用提供的敏感API
3. 应用权限管理也为用户提供了一些必须的功能方便用户查看和管理权限授予情况

应用权限管理为用户程序框架子系统提供权限管理功能并且为上层应用提供权限申请和授权状态查询接口。

标准系统应用权限管理此模块主要为标准系统用户程序框架子系统提供权限管理基础校验能力不对三方app开放代码目录kits  #外部接口层未提供并提供如下API

security\permission\interfaces\innerkits\permission_standard\permissionsdk\main\cpp\include\permission\permission_kit.h  

class PermissionKit

所有接口均为内部接口仅提供底层能力不对开发者开放。鉴权过程中直接调用VerifyPermission接口即可。

1. 明确要校验应用的UID及需要校验的权限名称permissionName
2. 根据UID获取应用的包名 bundleName
3. 根据UID获取应用的用户ID userId
4. 将需要校验的权限名permissionName, 包名bundleName和userId传入接口VerifyPermission(string permissionName, string bundleName, int userId)
5. 得到校验结果

int PermissionStateManager::VerifyPermission( const std::string& bundleName,

const std::string& permissionName, int userId) const

二、应用权限访问控制

ATM(AccessTokenManager)是OpenHarmony上基于AccessToken构建的统一的应用权限管理能力。Accesstoken信息主要包括应用身份标识APPID、用户ID应用分身索引、应用APL(Ability Privilege Level)等级、应用权限信息等。

ATM模块主要提供如下功能

1. 提供基于TokenID的应用权限校验机制应用访问敏感数据或者API时可以检查是否有对应的权限。
2. 提供基于TokenID的Accestoken信息查询应用可以根据TokenID查询自身的APL等级等信息。

主要的采取的策略访问控制列表ACL

ACLAccess Control List提供了解决低等级应用访问高等级权限问题的特殊渠道。

采用的授权方式权限类型可分为system_grant系统授权和user_grant用户授权。

这里的system和权限级别system不是一个概念系统授权是在App 安装时需要配置的不管级别的高低user_grant用户授权是弹框需要用户确认的权限就算是system级别的也需要提示

三、访问控制开发

默认情况下应用只能访问有限的系统资源。为了扩展功能的诉求需要访问额外的系统或其他应用的数据和功能系统或应用以明确的方式对外提供接口来共享其数据或功能。OpenHarmony提供了一种访问控制机制来保证这些数据或功能不会被不当或恶意使用即应用权限。

应用权限保护的对象可以分为数据和功能

1. 数据包含了个人数据如照片、通讯录、日历、位置等、设备数据如设备标识、相机、麦克风等、应用数据。
2. 功能则包括了设备功能如打电话、发短信、联网等、应用功能如弹出悬浮框、创建快捷方式等等。

应用权限是程序访问操作某种对象的通行证。

在进行权限的申请和使用时需要满足以下基本原则

• 应用申请的权限都必须有明确、合理的使用场景和功能说明确保用户能够清晰明了地知道申请权限的目的、场景、用途禁止诱导、误导用户授权应用使用权限必须与申请所述一致。
• 当前不允许应用自行定义权限应用申请的权限应该从已有的权限列表中选择。

应用APL权限等级说明

APL级别	说明
system_core等级	该等级的应用服务提供操作系统核心能力
system_basic等级	该等级的应用服务提供系统基础服务
normal等级	普通应用

1. normal权限该类型的权限仅向APL等级为normal及以上的应用开放

允许应用访问超出默认规则外的普通系统资源。这些系统资源的开放包括数据和功能对用户隐私以及其他应用带来的风险很小。

1. system_basic权限该类型的权限仅向APL等级为system_basic等级的应用开放

允许应用访问操作系统基础服务相关的资源。这部分系统基础服务属于系统提供或者预置的基础功能比如系统设置、身份认证等。这些系统资源的开放对用户隐私以及其他应用带来的风险较大。

    2.system_core权限影响程度非常大目前暂不向任何应用开放

涉及到开放操作系统核心资源的访问操作。这部分系统资源是系统最核心的底层服务如果遭受破坏操作系统将无法正常运行。

ACL 和APL的关系

    normal低级别的也可以申请system_grant系统授权

    system core高级别的同样需要申请 user_grant用户授权

   这两者的关系不是表面的那样

实际上它是一个很有用的特性如我们可以为某个函数定义一个默认的定义并将其用WEAK关键字修饰当调用该函数的用户希望其使用自己定义的特殊实现时就可以在其它的文件中重新定义一个非WEAK的同名函数此时链接器链接时就会链接新的定义而自动忽略掉用WEAK修饰的定义从而可以实现函数功能的扩展或者用于一些debug操作等。