未验证 提交 3e6c5e27 编写于 作者: O openharmony_ci 提交者: Gitee

!7902 安全文档修改

Merge pull request !7902 from zengyawen/master
......@@ -8,7 +8,7 @@
- 权限"ohos.permission.PERMISSION1"的权限等级为normal,权限类型为system_grant。
- 权限"ohos.permission.PERMISSION2"的权限等级为system_basic, 权限类型为user_grant。
> **注意事项:**
> **注意:**
>
> 当前场景下,应用申请的权限包括了user_grant权限,对这部分user_grant权限,可以先通过权限校验,判断当前调用者是否具备相应权限。
>
......@@ -28,11 +28,7 @@
不同的Ability框架模型的应用包结构不同,所使用的配置文件不同,请开发者在申请权限时注意区分。
### FA模型
使用FA模型的应用,需要在config.json文件中声明权限。
**config.json标签说明:**
配置文件标签说明如下表。
| 标签 | 说明 |
| --------- | ------------------------------------------------------------ |
......@@ -42,6 +38,10 @@
| abilities | 标识需要使用到该权限的元能力,标签为数组形式。 |
| when | 标识权限使用的时机,值为"inuse/always",表示为仅允许前台使用和前后台都可使用。 |
### FA模型
使用FA模型的应用,需要在config.json文件中声明权限。
**示例:**
```json
......@@ -112,34 +112,17 @@
如上述示例所示,权限"ohos.permission.PERMISSION2"的权限等级为system_basic,高于应用此时应用的APL等级,用户的最佳做法是使用ACL方式。
在配置文件声明的基础上,应用还需要在[profile文件](../quick-start/app-provision-structure.md)中声明不满足申请条件部分的权限。该场景中,用户应该在字段"acls"中做声明如下:
在配置文件声明的基础上,应用还需要在Profile文件中声明不满足申请条件部分的权限。Profile文件的字段说明可参考[HarmonyAppProvision配置文件的说明](../quick-start/app-provision-structure.md)
该场景中,用户应该在字段"acls"中做声明如下:
```json
{
"version-name": "1.0.0",
"version-code": 1,
"app-distribution-type": "os_integration",
"uuid": "5027b99e-5f9e-465d-9508-a9e0134ffe18",
"validity": {
"not-before": 1594865258,
"not-after": 1689473258
},
"type": "release",
"bundle-info": {
"developer-id": "OpenHarmony",
"distribution-certificate": "-----BEGIN CERTIFICATE-----\nMIICMzCCAbegAwIBAgIEaOC/zDAMBggqhkjOPQQDAwUAMGMxCzAJBgNVBAYTAkNO\nMRQwEgYDVQQKEwtPcGVuSGFybW9ueTEZMBcGA1UECxMQT3Blbkhhcm1vbnkgVGVh\nbTEjMCEGA1UEAxMaT3Blbkhhcm1vbnkgQXBwbGljYXRpb24gQ0EwHhcNMjEwMjAy\nMTIxOTMxWhcNNDkxMjMxMTIxOTMxWjBoMQswCQYDVQQGEwJDTjEUMBIGA1UEChML\nT3Blbkhhcm1vbnkxGTAXBgNVBAsTEE9wZW5IYXJtb255IFRlYW0xKDAmBgNVBAMT\nH09wZW5IYXJtb255IEFwcGxpY2F0aW9uIFJlbGVhc2UwWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAATbYOCQQpW5fdkYHN45v0X3AHax12jPBdEDosFRIZ1eXmxOYzSG\nJwMfsHhUU90E8lI0TXYZnNmgM1sovubeQqATo1IwUDAfBgNVHSMEGDAWgBTbhrci\nFtULoUu33SV7ufEFfaItRzAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0OBBYEFPtxruhl\ncRBQsJdwcZqLu9oNUVgaMAwGCCqGSM49BAMDBQADaAAwZQIxAJta0PQ2p4DIu/ps\nLMdLCDgQ5UH1l0B4PGhBlMgdi2zf8nk9spazEQI/0XNwpft8QAIwHSuA2WelVi/o\nzAlF08DnbJrOOtOnQq5wHOPlDYB4OtUzOYJk9scotrEnJxJzGsh/\n-----END CERTIFICATE-----\n",
"bundle-name": "com.ohos.permissionmanager",
"apl": "system_core",
"app-feature": "hos_system_app"
},
"acls": {
"allowed-acls": [
"ohos.permission.PERMISSION2"
]
},
"permissions": {
"restricted-permissions": []
},
"issuer": "pki_internal"
}
```
......@@ -151,7 +134,7 @@
如果校验结果显示,应用已经获取了该权限,那么应用可以直接访问该目标接口,否则,应用需要通过动态弹框先申请用户授权,并根据授权结果进行相应处理,处理方式可参考[访问控制开发概述](accesstoken-overview.md)
> **注意事项:**
> **注意:**
>
> 不能把之前授予的状态持久化,每次访问受目标权限保护的接口前,都应该检查权限授权状态,因为用户在动态授予后可能通过设置取消应用的权限。
......
......@@ -13,6 +13,18 @@ ATM(AccessTokenManager)是OpenHarmony上基于AccessToken构建的统一的
当前,ATM提供的应用权限校验功能是基于统一管理的TokenID(Token identity)。TokenID是每个应用的身份标识,ATM通过应用的TokenID来管理应用的权限。
## 权限使用的基本原则
在进行权限的申请和使用时,需要满足以下基本原则:
- 应用申请的权限,都必须有明确、合理的使用场景和功能说明,确保用户能够清晰明了地知道申请权限的目的、场景、用途;禁止诱导、误导用户授权;应用使用权限必须与申请所述一致。
- 应用权限申请遵循最小化原则,只申请业务功能所必要的权限,禁止申请不必要的权限。
- 应用在首次启动时,避免频繁弹窗申请多个权限;权限须在用户使用对应业务功能时动态申请。
- 用户拒绝授予某个权限时,与此权限无关的其他业务功能应能正常使用,不能影响应用的正常注册或登录。
- 业务功能所需要的权限被用户拒绝且禁止后不再提示,当用户主动触发使用此业务功能或为实现业务功能所必须时,应用程序可通过界面内文字引导,让用户主动到“系统设置”中授权。
- 当前不允许应用自行定义权限,应用申请的权限应该从[已有的权限列表](permission-list.md)中选择。
## 权限的工作流程
应用在访问数据或者执行操作时,需要评估该行为是否需要应用具备相关的权限。如果确认需要目标权限,则需要在应用安装包中申请目标权限。
......@@ -25,7 +37,7 @@ ATM(AccessTokenManager)是OpenHarmony上基于AccessToken构建的统一的
![](figures/permission-workflow.jpg)
1:应用可以参考下图,判断应用能否申请目标权限。
1:开发者可以参考下图,判断应用能否申请目标权限。
![](figures/permission-application-process.png)
......@@ -35,38 +47,6 @@ ATM(AccessTokenManager)是OpenHarmony上基于AccessToken构建的统一的
3:应用可以通过ACL(访问控制列表)方式申请高级别的权限,具体请参考[访问控制列表(ACL)说明](#访问控制列表acl说明)
## 权限使用场景说明
### 基本原则
在进行权限的申请和使用时,需要满足以下基本原则:
- 应用申请的权限,都必须有明确、合理的使用场景和功能说明,确保用户能够清晰明了地知道申请权限的目的、场景、用途;禁止诱导、误导用户授权;应用使用权限必须与申请所述一致。
- 应用权限申请遵循最小化原则,只申请业务功能所必要的权限,禁止申请不必要的权限。
- 应用在首次启动时,避免频繁弹窗申请多个权限;权限须在用户使用对应业务功能时动态申请。
- 用户拒绝授予某个权限时,与此权限无关的其他业务功能应能正常使用,不能影响应用的正常注册或登录。
- 业务功能所需要的权限被用户拒绝且禁止后不再提示,当用户主动触发使用此业务功能或为实现业务功能所必须时,应用程序可通过界面内文字引导,让用户主动到“系统设置”中授权。
- 当前不允许应用自行定义权限,应用申请的权限应该从[已有的权限列表](permission-list.md)中选择。
### 场景示例
下面列举两种应用需要使用权限的常见场景,用作参考。
- **视频播放类应用**
视频播放类应用要使用多媒体功能,应用必须对用户外部存储的媒体文件信息进行读取和写入,所以应用需要至少申请以下两个权限:
(1) ohos.permission.READ_MEDIA 允许应用读取用户外部存储中的媒体文件信息。
(2) ohos.permission.WRITE_MEDIA 允许应用读写用户外部存储中的媒体文件信息。
- **摄影美图类应用**
摄影美图类应用需要使用到相机功能,那么应用访问相机服务前,需要申请到相机权限:
(1) ohos.permission.CAMERA 允许应用使用相机拍摄照片和录制视频。
## 权限等级说明
根据接口所涉数据的敏感程度或所涉能力的安全威胁影响,ATM模块定义了不同开放范围的权限等级来保护用户隐私。
......@@ -85,7 +65,28 @@ ATM(AccessTokenManager)是OpenHarmony上基于AccessToken构建的统一的
默认情况下,应用的APL等级都为normal等级。
如果应用需要将自身的APL等级声明为system_basic及以上的APL等级,在开发应用安装包时,要修改应用的profile文件。在文件的"apl"字段声明应用的APL等级,并使用profile签名工具生成证书。具体签名流程可以查看页面[Hap包签名工具指导](hapsigntool-guidelines.md)
如果应用需要将自身的APL等级声明为system_basic及以上的APL等级,在开发应用安装包时,要修改应用的Profile文件。
在文件"bundle-info"的"apl"字段声明应用的APL等级后,使用[hap包签名工具](hapsigntool-overview.md)生成证书;也可以使用DevEco Studio[自动签名](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-auto-configuring-signature-information-0000001271659465#section161281722111)
> **注意:**<br>直接修改应用Profile文件的方式,仅用于应用/服务调试阶段使用,不可用于发布上架应用市场。如果需要开发商用版本的应用,请在对应的应用市场进行发布证书和Profile文件的申请。
示例如下:
该示例仅涉及修改"apl"字段,其余信息请根据实际情况。Profile文件的字段说明可参考[HarmonyAppProvision配置文件的说明](../quick-start/app-provision-structure.md)
```json
{
"bundle-info" : {
"developer-id": "OpenHarmony",
"development-certificate": "Base64 string",
"distribution-certificate": "Base64 string",
"bundle-name": "com.OpenHarmony.app.test",
"apl": "system_basic",
"app-feature": "hos_normal_app"
},
}
```
### 权限等级说明
......@@ -101,7 +102,7 @@ ATM(AccessTokenManager)是OpenHarmony上基于AccessToken构建的统一的
system_basic权限允许应用访问操作系统基础服务相关的资源。这部分系统基础服务属于系统提供或者预置的基础功能,比如系统设置、身份认证等。这些系统资源的开放对用户隐私以及其他应用带来的风险较大。
该类型的权限仅向APL等级为system_basic等级的应用开放。
该类型的权限仅向APL等级为system_basic及以上的应用开放。
- **system_core权限**
......@@ -179,8 +180,22 @@ ACL方式的工作流程可以参考[ACL方式使用说明](#acl方式使用说
在上述的[授权流程](#不同权限类型的授权流程)的基础上,应用需要进行额外的ACL声明步骤。
应用除了需要在config.json文件声明所需申请的权限,还需要在应用的[profile文件中声明](accesstoken-guidelines.md#acl方式声明)不满足申请条件的高等级权限,接下来的授权流程不变。
应用除了需要在应用配置文件声明所需申请的权限,还需要在应用的[Profile文件中声明](accesstoken-guidelines.md#acl方式声明)不满足申请条件的高等级权限,接下来的授权流程不变。
**ACL申请方式须知**
开发应用安装包时,需要修改应用的profile文件,在文件的"acl"字段声明目标的访问控制列表,并使用profile签名工具生成证书。具体签名流程可以查看页面[Hap包签名工具指导](hapsigntool-guidelines.md)
\ No newline at end of file
开发应用安装包时,需要修改应用的Profile文件,在文件的"acl"字段声明目标的访问控制列表。然后使用[hap包签名工具](hapsigntool-overview.md)生成证书。
> **注意:**<br>直接修改应用Profile文件的方式,仅用于应用/服务调试阶段使用,不可用于发布上架应用市场。如果需要开发商用版本的应用,请在对应的应用市场进行发布证书和Profile文件的申请。
```json
{
"acls": {
"allowed-acls": [
"ohos.permission.PERMISSION"
]
},
}
```
Profile文件的字段说明可参考[HarmonyAppProvision配置文件的说明](../quick-start/app-provision-structure.md)
\ No newline at end of file
......@@ -31,7 +31,7 @@ OpenHarmony系统内置密钥库文件,文件名称为OpenHarmony.p12,内含
1. 无应用签名证书场景:
开发者使用该工具对Hap包签名时,需按照签名步骤从第一步生成应用签名证书密钥对依次完成应用签名证书生成、profile文件签名、应用签名流程。
2. 有应用签名证书场景:
开发者可直接从签名步骤第三步对profile文件进行签名开始开发 ,使用应用签名证书和包含对应密钥的本地密钥库文件对应用进行签名。
开发者可直接从签名步骤第三步对profile文件进行签名开始开发使用应用签名证书和包含对应密钥的本地密钥库文件对应用进行签名。
### 命令说明
......
# Hap包签名工具概述
## 功能简介
为了保证OpenHarmony应用的完整性和来源可靠,在应用构建时需要对应用进行签名。经过签名的应用才能在真机设备上安装、运行、和调试。[developtools_hapsigner仓](https://gitee.com/openharmony/developtools_hapsigner)提供了签名工具的源码,包含密钥对生成、CSR文件生成、证书生成、Profile文件签名、Hap包签名等功能。
> **说明:** 针对无需通过ACL跨级别申请权限的应用,DevEco Studio为开发者提供了自动化签名方案,可以一键完成应用/服务签名。具体可参考[自动化签名方案](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/ohos-auto-configuring-signature-information-0000001271659465)。
## 基本概念
Hap包签名工具支持本地签名需求的开发,为OpenHarmony应用提供完整性保护和来源管控机制,该签名工具基于PKI公钥证书的机制实现,在进行开发前,开发者应了解以下基本概念:
......@@ -24,7 +24,7 @@ Hap包签名工具支持本地签名需求的开发,为OpenHarmony应用提供
HAP(OpenHarmony Ability Package)是Ability的部署包,OpenHarmony应用代码围绕Ability组件展开,它是由一个或者多个Ability组成。
- profile文件:
- Profile文件:
[HarmonyAppProvision配置文件](../quick-start/app-provision-structure.md),hap包中的描述文件,该描述文件描述了已授权的证书权限和设备ID信息等信息。
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册