TOWARDS A MULTI-MODEL VIEWS SECURITY

FRAMEWORK

Lei Xia, Hao Huang and Shuying Yu

State Key Laboratory for Novel Software Technology,Nanjing University,22 Hankou Road, Nanjing, China 210093

Keywords: Multiple model views, access control model, security model, security framework.

Abstract: With increasing diversity and complexity of the computing environments, various security needs in one

system can no longer be met by single access control model at the same time. An operating system should

be able to enforce multiple access control models. A Multi-Model Views Security Framework is proposed,

which is able to enforce multiple access control model views in operating system flexibly.

1 INTRODUCTION

Various security requirements are coming up with

the sharply increased diversity and complexity of the

computing environments (Rushby, 1992;

Saltzer,

1973

). To satisfy these security requirements, a vari-

ety of security models were proposed in last twenty

years. Currently widely-used security models in-

clude multilevel security model (BLP - Bell, 1975)

and its variants (Biba, 1977), Dion model (Dion,

1981), Domain and Type Enforcement (DTE)

(Walker, 1996; Badger, 1995), RBAC (Sandhu, 1996;

Sandhu, 1997), and etc. Each of these models aims

mainly at one or few security require- ments, such as

BLP aiming at the confidentiality assurance, Biba

aiming at integrity assurance, DTE aiming at con-

fining the information flow channels (

Rushby, 1992).

Previous operating system usually enforced only

one kind of access control model, for instance, Mul-

tics (Organick, 1972) implemented only BLP model

in it. However, as mentioned above,

the security

goals in different applications are various. These

different security requirements result in different

security models needed for them. How operating

system to support this kind of multiple security

model views needs?

As a policy neutral security model, RBAC pro-

vides a valuable level of permission abstraction.

However, using RBAC to simulate MLS or DAC

models (

Osborn, 2000) is over complex and therefore

unpractical in real-world operating system.

*This research is supported by National Natural Science Founda-

tion of China under grant 60473093.

The Multi-Model Views Security Framework

(MMVSF) is proposed. Several access control mod-

els are embodied in MMVSF, including BLP, Biba,

DTE and RBAC. These classical models can be eas-

ily enforced in MMVSF to implement multiple ac-

cess control model views in system.

The remainder is organized as follows. Section 2

formally describes the MMVSF. Section 3 gives the

examples of enforcing multiple access control model

views. And section 4 is the conclusion.

2 MMVSF

2.1 The Framework Overview

The architecture of the MMVSF is shown in figure 1.

MMVSF comprises of elements, relations and map-

pings. A user in the framework is a system user. A

role is a job function or job title within some associ-

ated authority. Subjects are active entities. Objects

are resource objects. Domain is a control access at-

tribute associated with each subject. And type is the

other control attribute associated with objects. Per-

mission is an approval of a particular mode of access

to object or interaction to subject. Security label

contains a confidentiality label and an integrity la-

bel.

There are several relations and mappings between

elements. user-role assignment relation, user-subject

relation, and subject-role mapping figure out the re-

lations between users, roles and subjects.

Xia L., Huang H. and Yu S. (2007).

TOWARDS A MULTI-MODEL VIEWS SECURITY FRAMEWORK.

In Proceedings of the Second International Conference on Security and Cryptography, pages 98-101

DOI: 10.5220/0002126200980101

 SciTePress

Figure 1: The MMVSF.

Permissions in system can be authorized to roles,

which are given in role-permission authorization re-

lation. Role-domain authorization relation gives the

authorized domains of each role. Each subject has

only one running domain, which is given in sub-

ject-domain mapping. Besides, each role has a secu-

rity label, and subject’s security label is determined

by its running role. Each object has a type and secu-

rity label.

The Final Permissions the subject gets are

based on three kinds of permissions correspond-

ing to that subject: MLS Permissions, Domain

Permissions, Role Permissions.

2.2 Formal Definitions

Table 1: Symbols of Elements Sets in MMVSF.

Set Name Symbol Set Name Symbol

Users U Subjects S

Objects O Domains D

Roles R Types T

Confidentiality

Labels

Integrity

Labels

z Security Labels: SL

⊆

C×I

z Access modes: M={read, write, execute, ...}.

z Domain transfer operation: transfer, denotes

subject transfer from one domain to another do-

main.

z Permissions: CAP ⊆ O×M. (o, m)∈AP denotes

permission to access object o in mode m.

Definition 2.2 US

⊆ U×S ， user-subject relation.

Many subjects can run on behalf of one user, but

each subject can only have one running user.

 user: S→U, mapping from subject to its

running user.user(s)=u if and only if u ∈

∧ (u, s) ∈ US.

Definition 2.3 UA

⊆ U×R, user-role assignment re-

lation. Each user can be assigned many roles and

each role can be assigned to many users.

 UR: U→2

, mapping from user to its assigned

role set: UR (u) = {r

∈R| (u, r)∈UA}.

 SR: S→R, subject-role mapping, from the

subject to its running role. Each subject’s run-

ning role be assigned to its running user: SR(s)

∈UR(user (s)).

Definition 2.4 RL: R→SL, mapping from role to its

security label.

 Ssl: S→SL, mapping from subject to its secu-

rity label. Subject’s security label is equal to

its running role’s label: Ssl(s)=RL(SR(s)).

Definition 2.5 RD

⊆ R×D, role-domain authoriza-

tion relation, a many to many relation.

 RDom: R→2

, mapping from role to its au-

thorized domains set.

RDom(r)={d ∈

D|(r, d) ∈ RD}.

 SDom: S→D, mapping from subject to its

running domain. Subject’s running domain

must have been authorized to its running role,

which means: SDom (s)

∈ RDom(SR(s)).

Definition 2.6 object’s security attribute

z OT: O→T, mapping from an object to its type.

z OL: O→SL, from an object to its security label.

Definition 2.7 RCAP

⊆ R×CAP, role-permission

authorization relation. (r1, cap)

∈ RCAP denotes

role r1 has the Role permission cap.

 Rolecap: R→2

CAP

, role’s authorized permissions

set. Rolecap(r)={cap| (r,cap) ∈ RCAP}.

Definition 2.8 Two control matrixes

z DTM: D×T→2

, domain-type access control

matrix. m∈DTM(d, t) denotes subjects in domain

d can access objects with type t in mode p.

z DDI: D×D→{Φ,{transfer}}, domain interaction

control matrix. transfer ∈ DDI(d

, d

) denotes

subjects in domain d

can transfer into domain d

Definition 2.9 Multilevel Security rule: Mls_rule:

SL×SL→2

, a∈Mls_rule(l

, l

) implies subjects with

security label l

can access target objects or subjects

with security label l

in mode a. All of BLP and Biba

security rules are implemented in this mapping. As a

framework, the concrete implementing of this func-

tion is not given here.

2.3 Permissions

z MLS Permission: mp(s,o)={(o,p)|p ∈ MLS_rule

(Ssl(s), OL(o))}.

MLS perms

Domain

Role perms

Perms

Role

Subject

Object

Label

Domain perms

Type

Label

User

Subject perms

TOWARDS A MULTI-MODEL VIEWS SECURITY FRAMEWORK

z Domain Permission: dp(s,o)={(o,p)|p ∈ DTM

(SDom(s), OT(o)).

z Role Permission: rp(s,o)={(o,p)|(o,p) ∈ Rolecap

(SR(s))}.

A subject’s Final Permissions on an object is deter-

mined as: fp(s,o)= rp(s,o)∪(mp(s,o)∩tp(s,o)).

3 ENFORCE MULTIPLE

MODELS

3.1 Enforcing Multilevel Security

Model

The way configuring MMVSF to enforce BLP

model is described as following:

(1) I={only_I}, there is only one integrity label in

system. |R|=|SL|, number of roles in the system

is the same as the number of the security labels.

Each role corresponds to one security label.

(2) D={gen_d}, T={gen_t}, only one domain and

type in system. RD={(r, gen_d)|r∈R}, all roles’

authorized domain is gen_d. all objects’ type is

gen_t: OT={(o, gen_t)| o∈O}.

(3) DTM={(d, t, p)|d ∈ D, t∈ T, p ∈ OM}, domain

gen_d have all Domain Permissions to type

gen_t.

(4) Rolecap(r:R)=Φ, each role has no Role Permis-

sions.

We can use the similar way to enforce Biba model.

3.2 Enforcing DTE

(1) R={gen_r}, one role in system. UA={(u,

gen_r)|u∈U}, gen_r is assigned to every user.

(2) RD={(gen_r, d)|d∈D}, all domains in system are

authorized to the role gen_r.

(3) SL={only_sl)}, only one security label in system.

RL={(r,only_sl)|r∈R}. MLS_rule(only_sl, only_

sl)=M, subjects’ MLS Permissions contain all

permitted modes in the set M.

(4) Rolecap(r:R)=Φ.

3.3 Enforcing RBAC

(1) D={gen_d}, T={gen_t}, one domain and one

type in system. RD={(r, gen_d)| r∈R}, gen_d is

authorized to every role and all objects’ type is

gen_t, OT={(o, generic_t)| o∈O}.

(2) DTM(gen_d,gen_t)=Φ, subjects in domain

gen_d have no Domain Permissions to all ob-

jects in type gen_t.

(3) SL={only_sl)}, only one security label in system.

RL={(r,only_sl)|r∈R}. MLS_rule(only_sl, only_

sl)= Φ.

3.4 Enforcing Multi-model Views

Assume all users in system can be divided into three

groups: Grpa, Grpb and Grpc. Now we hope that

the model enforced on users in Grpa is MLS, on

Grpb is RBAC and on Grpc is DTE. The configura-

tion that enforces this multi-model views in one

system is given below.

(1) U=Grpa∪Grpb∪Grpc, three disjointed subsets.

(2) R=mls_rs∪rbac_rs∪{dte_r}. mts_rs is the roles

set corresponding to MLS model. rbac_rs cor-

responding to RBAC and dte_r to DTE.

(3) D= {mls_d}∪{rbac_d}∪dte_ds.

(4) (u,r) ∈UA ∈ (u,r’)

∉

UA, where u∈ Grpa, r∈

mls_rs, r’

∉

mls_rs, roles in mls_rs are only per-

mitted to be assigned to users in Grpa. (u, r) ∈

UA∈ (u,r’)

∉

UA, where u∈Grpb, r∈ rbac_rs,

r’

∉

rbac_rs, roles in rbac_rs can only be as-

signed to users in Grpb. In the same way, (u,

dte_r) ∈ UA ∈ (u, r)

∉

UA, where u∈Grpc, r≠

dte_r.

(5) |mls_rs|=|SL|, number of roles in set mls_rs is the

same as number of security labels in system.

Each role in mls_rs corresponds to one security

label. MLS_rule(Ssl(r),tsl)=Φ, r∈ rbac_rs, tsl∈

SL, roles in rbac_rs have no MLS Permissions.

MLS_rule(Ssl(dte_r),tsl)=M, tsl∈SL, role dte_r’s

has all of possible MLS permissions.

(6) (r,mls_d) ∈ RD ∈ (r,d)

∉

RD, where r∈mls_rs,

d ≠mls_d, roles in mls_rs are only authorized

domain mls_d. (dte_r,d) ∈ RD ∈ (r’,d)

∉

RD,

r’≠dte_r, d∈dte_ds, all domains in dte_ds are

authorized to role dte_r. Simliarly, (r,rbac_d) ∈

RD∈ (r,d)

∉

RD, where r∈rbac_rs, d≠rbac_d,

roles in rbac_rs are only authorized domain

rbac_d.

(7) (mls_d,t,m) ∈DTM, t∈T, m∈M. DDI(mls_d, d)=

Φ, d∈D, subjects in domain mls_d can not trans-

fer to any other domains. Similarly, (rbac_d,

t,m)

∉

DTM, t∈T, m∈M. DDI(rbac_d,d)=Φ, d∈D.

(8) Rolecap(r)=Φ, r∈mls_rs∪{dte_r}. dte_r and all

roles in mls_rs have no Role Permissions.

SECRYPT 2007 - International Conference on Security and Cryptography

100

4 CONCLUSION

The MMVSF security framework provides a way to

easily enforce multiple access control models in an

operating system to satisfy the diverse security re-

quirements in one system.

REFERENCES

Badger, L., Sterne, D. F. and Sherman, D. L., et al, 1995.

A Domain and Type Enforcement UNIX Prototype. In

Proceedings of the Fifth USENIX UNIX Security

Symposium.

Bell, D. and LaPadula, L., 1975. “Secure Computer Sys-

tems: Mathematical Foundations”, Technical Report

MTR-2547, MITRE Corporation, Vol. I, MTR-2997

Rev.1.

Biba, K., 1977. Integrity Considerations for Secure Com-

puter Systems. MITRE Corporation, Technical Report

MTR-3153.

Dion, L. C., 1981. A complete protection model. In Pro-

ceedings of the IEEE Symposium on Research in Se-

curity and Privacy, 49-55.

Organick, E., 1972. The MULTICS System: An Examina-

tion of Its Structure. The MIT Press.

Osborn, S., Sandhu, R. and Munawer, Q., 2000. Config-

uring Role-based Access Control to Enforce Manda-

tory and Discretionary Access Control Policies. ACM

Transactions on Information and System Security,

Vol.3, No.2, Pages 85-106.

Rushby, J., 1992. Noninterference, Transitivity, and

Channel-Control Security Policies. Computer Science

Lab, SRI International, Technical Report CSL-92-02.

Sandhu, R., Coyne, E., Feinstein, H. and Youman, C.,

1996. Role-Based Access Control. IEEE Computer.

Vol.29, No.2.

Sandhu, R., 1997. Rational for the RBAC96 Family of

Access Control Models. In Proceedings of 1st ACM

Workshop on Role-based Access Control.

Walker, K. M., Sterne, D. F. and Badger, M. L., et al, 1996.

Confining Root Programs with Domain and Type En-

forcement (DTE). In Proceedings of the 6th USENIX

UNIX Security Symposium.

TOWARDS A MULTI-MODEL VIEWS SECURITY FRAMEWORK

101