OSGi R4服务平台核心规范 :第九章 条件权限管理规范(1)

 由  满江红开放技术研究组织 发布

版本号: 1.0

9.1.简介

OSGi安全模型是基于功能强大,适应性强的Java 2安全架构,特别是它的权限模型。本规范在此基础上增加了一些特性,以适应OSGi开发人员的一些特殊要求。

与其他Java执行模型相比,OSGi框架提供了良好定义的API来进行权限管理,而其他的执行模型将权限管理留给具体的开发实现。

安全管理API的一个关键特性就是进行实时的权限控制。这就使得可以对其他应用的权限管理可以立即生效,而不需要重新启动。

权限管理是基于一般的条件权限模型。bundle使用OSGi联盟或者是用户定义的条件来和条件权限进行匹配。这种模型的优点就是组权限可以通过签名者和区域信息进行共享。条件模型也可以用于当满足特定条件时,则启用一组权限,例如,内置的SIM卡,建立了管理系统的在线连接,或者是当提示后用户批准了一项权限。这个模型允许操作者为他们的设备创建并执行一个动态的安全策略。

本规范定义了条件权限管理来代理权限管理(虽然它和权限管理的关系在本规范中已经进行了定义)。通过条件权限来提供一个安全模型,条件定义了这些权限应用的bundle的选集。

9.1.1.要点

  • Policies 提供了一个安全策略系统,在这个系统中,外部条件控制对某一时刻的bundle的权限进行控制。
  • Java 2 Security - 对Java 2安全模型提供了全部兼容,现有的系统无须修改。
  • Delegation - 提供了代理管理模型,操作者可以将对设备的部分安全管理委托给另一方。
  • Digital Signatures - 在bundle的决策机制中支持使用数字签名。
  • Real Time - 环境的改变必须马上影响到bundle的权限。
  • Operator Specific Conditions - 操作者、开发厂商、选择的开发者和其他人可以提供定制的条件。
  • User Confirmation - 策略模型必须支持终端用户的审批和配置。
  • Backward Compatibility - 模型必须要向后兼容原来发布的权限管理。

9.1.2.名词

  • Conditional Permission Admin – 提供了对权限表格进行操作功能的管理服务。
  • Permission Table – 一种包含了所有条件权限信息的概念上的表格。
  • Conditional Permission Info – 条件信息对象集合和权限信息的集合的笛卡儿积。
  • Permission Info – 带有字符串编码的权限对象。
  • Condition Info – 带有字符串编码的条件对象。
  • Condition – 条件对象关联到一个bundle的保护域,并且可以在任何时候通过计算抽象出一个条件的表示。
  • Bundle Location Condition –提供一个不变的条件对象来满足当关联的bundle具有给定位置时的情况。
  • Bundle Signer Condition – 提供一个不变的条件对象来满足当关联的bundle的证书是由一个指定DN签名的情况。
  • Permission – 定义了特定权限类型的对象。
  • Bundle Protection Domain – 实现了bundle保护域的类,这个规范没有定义类的接口,但是在这个规范中起着很重要的作用。

【图片9.1.2.1】

9.1.3.大纲

条件权限管理服务包括了一个系统级的ConditionalPermissionInfo对象表格,这些对象编码格式为条件对应权限。管理员可以列举、删除和添加新的条目到表格中。

当创建了一个bundle之后,也创建了一个对应的惟一的bundle保护域。这个保护域给通过初始化在权限表格中定义的条件和权限值来给bundle计算其系统权限,计算过程中也同时删除了bundle不会使用的部分,并优化其经常使用的条目。

在bundle中可以有通过bundle权限资源来定义的局部权限。这些是bundle实际需要的操作权限。bundle的有效权限集合是局部权限和系统权限的交集。在基于Java安全管理进行权限检查时,保护域首先检查局部权限,如果检查失败,那么整个检查过程失败。

否则,bundle保护域检查调用bundle是否隐含请求的权限。为了隐含请求权限,bungle保护域必须在它的所有满足条件的权限表格中查找到一个元组,这个元组的权限隐含了请求权限。但是,特定的条件必将推迟计算以便于将计算成组进行。例如,一个用户命令必须延期执行,这样来清除终端用户的任何冗余问题。只有当这些条件关联的权限隐含了请求权限,而请求又不能马上满足的时候,这些条件式才会延期执行。

权限检查的最后阶段,由延期的条件式所在的类对它们进行成组计算。

9.1.4.阅读指南

9.1.4.1.架构师

  • 权限管理模型
  • 条件权限
  • 条件
  • 数字签名JAR

    9.1.4.2.应用开发人员

  • 数字签名JAR

    9.1.4.3.管理人员

  • 权限管理模型

  • 条件权限
  • 条件
  • 条件权限
  • 权限管理
  • 数字签名JAR
  • 标准条件式

9.2.权限管理模型

条件权限管理模型提供了对bundle的灵活性非常强的安全模型。然而,高度灵活性也带来了复杂度的提高。在这种情况下,为了设置一个工作环境需要进行大量的配置,这是非常繁重的工作。因此,框架实现的时候要特别注意对安全模型的实现。本节定义了一系列可行的实现方案,并定义了一些术语来详细解释这种机制。

9.2.1.局部权限

一种好的原则就是尽可能最小化权限,并且尽可能早的设置权限。这种原则的一个实现就是通过局部权限来控制。局部权限通过嵌入到bundle中的bundle权限资源(Bundle Permission Resource)来定义;它定义了一系列权限。框架通过这些权限来限制指定bundle,也就是说,bundle可以获得比局部权限少的权限,而绝不能获得比局部权限更多的权限。如果没有这样的资源,那么局部权限默认就是全部的权限(All Permission)。关于bundle权限资源可以参阅Bundle Permission Resource一节。

例如,如果局部权限中没有定义ServicePermission[org.osgi.service.log.LogService,GET],那么bundle就绝不能获得LogService这个对象,而不管是否有其他的安全设置。

OSGi支持的局部权限是一种小粒度的权限,这种方式非常有效,这是由于可以通过开发人员来定义而不是由部署人员进行定义。开发人员非常明确的知道他所需要的服务,所需要的bundle的包,所需要访问的网络服务器等。而且,可以通过工具来分析bundle,获得适当的局部权限。这样就可以简化开发人员的工作。但是,如果不知道bundle的内部结构,那么对于这种小粒度的权限,是很难创建出局部权限的。

初步看来,bundle带有自己的权限是多余的。但是,局部权限定义了bundle所需要的最大权限,由于框架不允许bundle使用其它的权限,那么就没必要提供给bundle的更多不相关的权限。因此,局部权限的目的就是由部署人员来进行审核。为安全需求而对bundle的字节码进行分析是非常麻烦的事情,而不是不可能的。与之相比,对bundle的权限资源进行审核则更加直接。例如,如果局部权限请求访问因特网的权限,这也就说明了bundle潜在的希望访问网络。通过对局部权限的检查,操作者可以很快就能获得bundle的安全区域。核查是可信的,这是由于在执行bundle的时候,是由框架强制进行的。

运行封闭系统的操作者可以通过局部权限来运行第三方的应用程序,这些程序是不可信的需要进行运行检查,这样就降低了风险。框架绝不会授予在局部权限中没有隐含的权限。对应用的局部权限进行简单的检查就可以暴露出潜在的威胁。

本方案可以通过下图来进行描述。开发人员通过局部权限创建了bundle,操作者对局部权限进行确认,如果局部权限与预期值匹配, 那么就部署这个设备,而框架则对设备进行局部权限检查。

【图片9.2.1.1】

对于局部权限的优点总结如下:

  • 细粒度(Fine-grained) – 开发人员熟知对于bundle这个沙盒最少需要提供哪些细粒度的权限而使得bundle不会有约束。
  • 核查(Auditable) – 与操作者的关联度很小,而且可以通过可读文件来展示需要的沙盒。因此可以接受运行bundle的风险。
  • 沙盒(Sandboxed) – 操作者通过框架来授权,而bundle的权限不会超过局部权限。

9.2.2.开放式部署通道

从业务角度来看,如果是维持一个完全封闭的系统是过于严格。很多情况下,用户都需要从CD、其他PC、或者是因特网来下载部署bundle。在这些情况下,仅仅依赖于局部权限不足以满足这样的要求,这是由于框架不能够确认局部权限是否已经被篡改过了。

实际篡改的是bundle的数字签名。OSGi签名规则在JAR文件的数字签名一节中已经定义。数字签名算法可以检测到对JAR文件的修改以及对签名者验证信息的修改。因此,框架必需拒绝运行一个签名不匹配或者是签名者不可识别的bundle。因此,签名机制使得框架可以使用一种不可信的部署通道,同时也依赖于局部权限的强制性。

例如,操作者可以通过因特网来提供应用。当用户从一个不可信的网站下载了一个应用之后,框架对签名信息进行校验。只有当签名是可信的,或者对不可信bundle具有默认权限时,框架才会安装这个应用。

【图片9.2.2.1】

9.2.3.代理

具有局部权限的模型通过操作者签名来对设备进行安全控制。在提供服务之前,操作者必须要对所有的bundle进行签名。这种情况下,操作者实际上扮演了一个看门人的角色,而没有任何授权代理。

当包含了第三方的情况下,这种操作的代价就非常高昂。例如,一个企业通过对顾客移动电话提供应用服务,由操作者进行管理。下图描述了这种模型。如果企业在每次发布一个新版本都需要与操作者进行交涉,那么瓶颈就凸现了。

【图片9.2.3.1】

这个瓶颈问题可以通过签名来解决。签名不仅仅提供了篡改检测机制,也提供了已确认负责(principal)。负责人是通过证书链来验证为已确认的。设备中包括了一系列的可信证书(根据具体实现而不同),用于对签名者的证书进行校验。

因此,操作者就可以安全的将一个负责人与一系列的权限关联。这些权限称之为系统权限(system permissions)。而框架对所有负责人签名的bundle都授予这一系列系统权限。

在这种模型中,操作者依然拥有全部的控制。在任何时候,操作者都可以根据需要来改变关联的负责人的系统权限,即使是正在运行这些应用。同样的,当签名者的一个新的服务可用之后,操作者也可以实时的给负责人授予需要的系统权限,可以给负责人授予权限来使用服务。例如,如果操作者安装了一个新的服务org.tourist.PointOfInterest service,那么就可以给所有的负责人授予权限: ServicePermission[org.tourist.PointOfInterest,GET]和PackagePermission[org.tourist, IMPORT]权限,授权后就被允许使用这些服务了。然后,操作者就可以通知相关的第三方。因此,这个模型就不会产生瓶颈。

使用数字签名来分配系统权限也因此可以交由第三方来代理。操作者只要定义了负责人的权限的限界,而签名和部署就可以交由第三方来完成。

例如,操作者可以定义ACME公司可以提供bundle而无须操作者干涉。操作者只需一次性的提供签名证书,并将ACME负责人和适当的系统权限在设备上关联。

这种模型的主要优点是减少了ACME和操作者之间的通讯。操作者可以修改ACME公司应用的系统权限,并且在任何时候都可以及时的控制。ACME公司开发的新应用也不需要进行协调了。下图描述了这种模型,同时也展示了Daffy公司的未验证bundle沙盒的可能情况。

【图片9.2.3.2】

在代理模型中,局部权限依然起着重要的作用,这是由于它提供给签名者降低风险的可能,就如同它降低了操作者的风险一样。签名者可以在对bundle签名之前校验局部权限。例如,如果一个游戏bundle请求权限:AdminPermission[,],那么很可能bundle不会通过签名者的安全检查。但是,即使在不太可能的情况下确实通过了检查,那么如果操作者没有授予签名负责人在设备上这样的权限,bundle将不会获得这样的权限。

9.2.4.组模型

使用传统上的组模型是由于这样可以减小安全设置的管理。例如,操作者可以定义如下的安全级别:

  • 不可信(Untrusted) – 不可信的应用。这些应用必须要在最小安全范围内运行。这些应用可能是未签名的。
  • 可信(Trusted) – 可信的应用。不允许对设备进行管理或者是提供系统服务。
  • 系统(System) – 提供系统服务的应用。
  • 管理(Manage) – 管理设备的应用。
  • 在部署bundle之前,操作者使用适当的证书给bundle进行签名,当安装bundle时,将自动把bundle放置到适当的安全区域中。
  • 然而,也可以通过使用bundle的局部权限来达到同样的目的。
9.2.5.典型示例 这些示例提供了代理模型的一个简单设置。为增加可读性,这个示例中有一些概念,将在后文中进行解释。同样也是为了可读性,可以猜测的包前缀都使用“…”来替代。 基本的权限定义了对于所有bundle都有的权限。因此,基本权限是没有条件关联的,所有的bundle都可以使用这些权限:

【图片9.2.5.1】
下一个权限元组是有条件的,定义了ACME公司签名的bundle具有的权限界限。ACME签名的bundle具有管理其他bundle的权限。条件式在方括号中进行描述:

【图片9.2.5.2】
最后一个权限元组是定义了操作者签名的bundle。操作者的bundle具有所有的管理权限,并且具有提供系统服务的权限:

【图片9.2.5.3】

授权结果如下表所示:

表格 11 分配的权限和通过其他权限隐含,x表示直接包含,i表示通过其他权限隐含

签名者

权限

未签名

ACME

操作者

Service Permission

..LogService

GET

x

x

x/i

..ManagedService

REGISTER

x

i

*

GET

i

*

x

PackagePermission 

..log

IMPORT

x

x/i

..cm 

IMPORT

x

i

..framework

IMPORT

x

x

x/i

*

x

AdminPermission

(signer=\*;o=ACME) 

*

x

i

*

x

9.3.有效权限

一旦安装完成bundle之后,也就关联了Java 2的权限。这个集合称之为有效权限。当调用安全管理的checkPermission方法时,访问有效权限。

管理应用可以通过权限管理服务和有条件权限管理服务来定义系统权限(system permissions)。另外,bundle也有自身的权限,称之为局部权限(local permissions)。所有的这些权限集合通过内部交互后得到有效的权限。

局部权限的作用是减小bundle签名者的风险。框架保证了bundle的有效权限通常要比小于或者等于局部权限,这是由于有效权限集合是局部权限与系统权限的交集。

【图片9.3.1】

系统权限来自于两种可能的途径。一种是通过位置的权限管理服务。这种机制仅仅是为了兼容原来的版本。新开发的管理应用应该尽可能使用条件权限管理服务。

如果不能对权限管理进行定位,那么所有来自条件权限管理的条件权限充当系统权限。系统权限和局部权限的关系如图43所示:

【图片9.3.2】

9.4.条件权限

条件权限提供了和Java 2策略模型(Policy mode)相关但是又不一样的更加一般化的模型。Java 2策略模型将一系列的权限分配给代码或者是签名者。

在条件权限管理服务模型中,采用了一种更加通用的方法。在系统范围内拥有一个概念上的权限(permission table)。如果权限表中的任一条目符合正确的条件式,那么它对任何bundle都是可用的。

表格中的元组由以下元素组成:

  • 一组条件式
  • 一组权限

只有当权限检查时,满足了所有的条件式,那么才能应用元组中的权限。本规范提供了某些条件类型,其他的条件类型可以由用户代码提供。例如,当相关bundle是由一个指定负责人签名时,可以满足bundle签名条件。如果bundle不是由这个负责人签名的,那么在检查过程中,不能应用元组的权限。

条件式的一种实现是通过Condition接口来表示,它表示为一个表达式,在权限检查过程中,可以计算出表达式的值为true或者false。必须将条件集合进行AND操作。只有满足了所有的条件,那么元组才能匹配并应用权限。也就是说,元组(conditions, permissions)满足以下条件时,隐含了权限P:

  • 满足了所有的条件。
  • 至少有一个权限隐含了P,就如在Java 2安全中定义的那样。 Condition对象的另一个特点就是对它们的计算可以推迟到权限检查的最后进行。推迟计算使得一种Condition类型进行成组对相同的条件表达式进行求值。这也就是说,例如,提示用户的重要信息。直接计算即时的条件。在条件生命周期中进行了详细描述。 例如,考虑如下对bundle A的设置:

【图片9.4.1】

花括号{}中定义了一个单独的元组。在方括号[]中包含了条件式,权限则用小括号()表示。通常,为了简短起见,省略了包前缀。在文档的其余部分也使用了这种语法结构。

示例展示了在对任何一个bundle授予运行生命周期操作的管理权限之前,必须要同时满足的条件org.osgi.service.condpermadmin.BundleignerCondition和条件com.acme.Online。

将条件权限和bundle进行绑定是很常见的,虽然不是必须的。因此,提供了一系列的Condition类来定义bundle的系统权限。这种关联依赖于具体的bundle:

  • Signer – 实现了类BundleignerCondition。
  • Location –实现了类BundleLocationCondition。

bundle的系统权限是动态易变的,这也就是为什么隐含方法的调用依赖于当权限检查时满足的条件式。原则上,系统范围内的权限表中任何元组都是可以匹配的。

9.4.1.实例对应编码

系统范围权限表由方法addConditionalPermissionInfo(ConditionInfo[],PermissionInfo[]) 或者方法setConditionalPermissionInfo(String,ConditionInfo[],PermissionInfo[])来维护。这些方法使用了条件式和权限表达式的编码形式。这种编码形式保存在权限表中。权限表就象是Bundle Protection Domain的一个动态模板,Bundle Protection Domain创建相关bundle的一个接口作为上下文环境。这是动态的,是由于Bundle Protection Domain必须要即时跟踪对权限表格的修改,并且立即更新其为最新的编码形式。一旦方法addConditionalPermissionInfo(ConditionInfo[], PermissionInfo[]) 或者 setConditionalPermissionInfo(String,ConditionInfo[], PermissionInfo[])返回,那么以后对Bundle Protection Domain的使用必须是基于这个新的组合体。

【图片9.4.1.1】

方法addConditionalPermissionInfo的参数是ConditionInfo和PermissionInfo对象(来自包org.osgi.service.permissionadmin)。这些对象的目的在于对条件和权限进行编码而不是初始化。方法addConditionalPermission的返回值也是一个对条件和权限进行编码的对象:一个ConditionalPermissionInfo对象。

权限表中的条件和权限必须在进行条件检查之前进行初始化。。初始化的过程发生在创建Bundle Protection Domain时或者是由于权限检查而第一次需要条件权限的时候。因此,Condition对象必须是属于一个单独的Bundle Protection Domain,而且不能共享。相反的,Permission对象是上下文无关的,可以在不同的Bundle Protection Domain之间进行共享。


wocalage 2015-09-06 16:43

没有啦?

顶(1) 踩(0) 回复
查看评论