鸿蒙应用权限管理和访问控制_鸿蒙系统怎么防止被控制

目录

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

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

二、应用权限访问控制

三、访问控制开发

---

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

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

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

2.访问控制列表（ACL）

ACL（Access 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）

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

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

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

三、访问控制开发

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

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

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

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

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

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

应用APL权限等级说明

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操作等。