卿 斯 漢中國科學院軟體研究所

2003 年 11月

2/36

大綱 引言 支持多策略的形式架構 DMLR_MLS 模型 DTE_IPM 模型 PCM_RBPC 模型 小結

3/36

引言

安全作業系統的重要性 : 機密性－ BLP模型 完整性－ Biba模型； Clark-Wilson模型 可用性－？？？模型 作業系統是安全產品的底座 Fortress built upon sand

4/36

形式模型的基本結構

一個支援多安全策略的動態管理的形式模型應該包括以下幾個部分：把多個策略模型動態地組織在一起的多策略形式架構，把策略轉化為系統可執行模型的模型規範語言，及系統將執行策略的各策略分量的模型的集合。它們的關係如下圖所示：

5/36

形式模型的基本結構

支持多策略形式架構支持多策略形式架構

模型規範語言模型規範語言

分量策略模型簇分量策略模型簇

模型結構示意圖

6/36

形式模型的基本結構 支持多策略的形式架構－－多策略有

效控制一個系統的基礎，它解決策略等價，策略衝突分解及策略協作等問題。

根據形式架構的需要，模型還必須有相應的配套語言，它用於形式地描述系統的各種安全策略，把安全策略轉化為容易利用程式語言表達的模型。

7/36

支持多策略的形式架構

假設系統的安全策略可由 n 形式模型 描述 , 這些模型的每一個都

可以被吊銷， 而且其他新策略模型也可以添加到該架構中。 在這些假設條件下，這個架構主要由一簇模型介面介面 ，及一個模型組合器組成。它們的關係可由下圖表示。

niM i ,,1

niInterfacei ,,1

8/36

支持多策略的形式架構

Formal model Mi

Interface

1

……… Interface(n-

1)

Interfacen

Model combiner

System subject

System object

支援多策略環境的一般架構

9/36

支持多策略的形式架構 模型介面介面是一個虛擬模型，當系

統給該介面發出請求時，它把該請求轉發給實際的模型，實際模型作出決策，並把決策傳給介面，介面把實際模型的決策轉化介面的決策，從而這個虛擬模型替代實際模型實現策略控制。不同模型可以有不同的決策方式，為統一它們因而提出介面概念。

10/36

支持多策略的形式架構

模型組合器是本架構的重點，它由模型衝突類劃分關係，模型衝突分解關係，及模型協作關係組成。它們的關係可由下圖表示。

11/36

支持多策略的形式架構

M1, M2, M3 , M4, M5, …, Mn

1 21s-1

s………

D D D D………

D

（圖中代表衝突劃分關係， i 劃分衝突類， 代表衝突分解關係，代表協作關係）

12/36

舉例說明

我們的系統將要使用的基本模型集合是 { DAC , MLS , DTE, RBAC }

決策集是 {YES, NO, DC, UNDEFINED}

衝突類有： { DAC, RBAC }, {MLS , RBAC }, { DTE }

13/36

舉例說明 模型 DAC 介面介面定義如下：

=

operationanrecognizetdoesnDACifUNDEFINED

itforchecksrequiretdoesnbutoperationanrecognizesDACifDC

sstateonoperationangrantcannotbutevaluatecanDACifNO

sstateonoperationangrantandevaluatecanDACifYES

'

',

,)(sInterface

DAC

14/36

舉例說明 策略衝突分解關係定義如下 (1) ：

otherUNDEFINED

DCsterfaceInandDCsterfaceInifDCNOsterfaceInandDCNOsterfaceInor

DCNOsterfaceInandNOsterfaceInifNO

YESsterfaceInandDCNOsterfaceInor

DCsterfaceInandYESsterfaceInifYES

RBACDAC

RBACDAC

RBACDAC

RBACDAC

RBACDAC

)()()(,)(

,)()()(,)(

)()(

( DAC, RBAC)=

15/36

舉例說明 策略衝突分解關係定義如下 (2) ：

otherUNDEFINED

DCsterfaceInandDCsterfaceInifDCNOsterfaceInandDCNOsterfaceInor

DCNOsterfaceInandNOsterfaceInifNO

YESsterfaceInandDCNOsterfaceInor

DCsterfaceInandYESsterfaceInifYES

RBACMLS

RBACMLS

RBACMLS

RBACMLS

RBACMLS

)()()(,)(

,)()()(,)(

)()(

( MLS , RBAC)=

16/36

舉例說明 策略衝突分解關係定義如下 (3) ： ( DTE)= DTEInterface

17/36

舉例說明

? YES NO DC UNDEFINED

YES YES NO YES UNDEFINED

NO NO NO NO UNDEFINED

DC YES NO DC UNDEFINED

UNDEFINED UNDEFINED UNDEFINED UNDEFINED UNDEFINED

運算⊕規則表

最後，我們定義協作關係。為了定義協作關係，我們先定義決策集上的運算⊕，其規則如下圖所示。

18/36

舉例說明

協作關係定義為：

這個過程可由下表表達：

)(),(),( DTERBACMLSRBACDAC

19/36

舉例說明Check DAC Access If DAC access is denied, check RBAC capabilities If overrides fail, deny accessAND Check MLS Access If MLS access is denied, check RBAC capabilities If overrides fail, deny accessAND Check DTE Access If DTE access is denied, deny access HAVE DAC, MLS, DTE and RBAC, so allow access.

20/36

DMLR_MLS 模型 The idea of having rules that

mediate integrity levels dynamically was first introduced by Biba in his low-water mark integrity model long time ago. The new idea of having rules that mediate current confidentiality levels dynamically was first introduced by Ott recently in 2001.

21/36

DMLR_MLS 模型

But his proposal leads to cost increasing of the system. In addition, his method of introducing an additional level range for every subject is inconsistent with Bell’s suggestion that replacing current level by a level range for trusted subjects.

22/36

DMLR_MLS 模型

In the following, we present a new model, called the DMLR_MLS model, laying emphasis upon some new rules and concepts.

23/36

DMLR_MLS 模型 Main Theorem Suppose the system satisfies the

*-property and follows the rules for dynamically mediating the subject’s security clearance range described above, if oi (i=1,2) only has single security level, i.e. O-min(o1)= O-max(o1), O-min(o2)= O-max(o2), and there exists a subject s, such that (s, o2, append)b and (s, o1, read)b , then either we have O(o1) ≾O(o2), if s is not a trusted subjects; or we have O(o1) ≾O(o2) or O(o1), O(o2)ran(s), if s is a trusted subject.

24/36

DTE_IPM 模型 The DTE_IPM model consists of two

main parts: the certification rules and the integrity protection state transition model. The purpose of the certification rules is to show how domains and types should be configured to implement the security invariants, and what assurance measures should be taken to achieve the integrity goals.

25/36

DTE_IPM 模型 There are four types of events defined by

the system: operational event, access event, access override event, and audit event. Operational event is a check to determine whether a subject has appropriate privilege to perform a restricted operation (e.g., mounting a file system, or adding a new user).

26/36

DTE_IPM 模型 Access event is a check to determine

whether a subject can gain a requested mode of access (e.g., read) to an object. Access override event is a check to determine whether a subject has appropriate privilege to override a denial of access by an access control policy (e.g., override an ACL denying read access to a file).

27/36

DTE_IPM 模型 Audit event is a check to determine

whether a security-relevant occurrence should be recorded in the system audit trail. If so, the record is created and added. This model only copes with integrity aspects relevant to access events, operational events and access override events are left to be dealt with by the PCM_RBPC model.

28/36

PCM_RBPC 模型

PCM_RBPC model is to be used to deal with operational events and access override events. In order to effectively control operational events and access override events it is necessary to enforce the least privilege principle in the system.

29/36

PCM_RBPC 模型 It is well known that POSIX 1003.1e has

proposed a good capability mechanism, but it does not define either the notion of executable file capabilities or the notion of user capabilities. Most importantly, it does not provide a capability inheritance algorithm which is essential to compute capability sets.

30/36

PCM_RBPC 模型 Our new algorithm is as shown

below.

31/36

PCM_RBPC 模型 where two new capability sets, namely

Br and Bd are introduced while other capability sets have their usual meaning. Br is role capability set, which is determined solely by the role’s id, irrelevant to the user’s uid. Bd

is domain capability set that determined solely by the domain’s id.

32/36

PCM_RBPC 模型

We have introduced eight new invariants in the model. These important invariants will help in the understanding and analysis of the security model in SELinux.

33/36

小結

We have made several contributions to the field of secure operating system design. First, a formal framework different from and more powerful than the existing ones has been proposed aiming at supporting multiple application-specific security policies in modern computing environments.

34/36

小結

Then three novel models in the different areas, namely the confidentiality policy model DMLR_MLS, the integrity policy model DTE_IPM, and the extended role-based access control model PCM_RBPC for controlling process privileges have been introduced, all of which have a number of desirable new features.

35/36

小結

It is our hope that methods such as the ones we present in this paper will help in the development of operating systems with higher assurance of security.

36/36

Q & A

Thank you