Transcript Venkateshwarlu Jangili`s presentation on Design and

1
Design and Implementation MAC
in Security Operating System
CAI Yi , ZHENG Zhi-rong , SHEN Chang-xiang
Presented By,
Venkateshwarlu Jangili.
2
Outline:
•
•
•
•
•
•
•
•
•
Introduction
Mandatory Security Model
What is BLP
Defining Security Policy
Security Levels
Security Policies
Defining Security Level
Multi-Level Directories
Conclusion
3
Introduction:
• MAC – Mandatory Access Control
• Users and Resources in the system are defined
subjects and objects separately and abstractly by
MAC.
• Security of system directly depends on operating
system services and mechanisms.
• How is the System made Secure….???
4
Contd…
• MAC Mechanisms are added to the OS.
• Users and Information in a system are assigned
sensitivity labels that are a combination of
Hierarchal and Non Hierarchal categories.
• Labels are the basis for MAC decisions.
• Subjects and Objects.
5
Mandatory Security Model
• Security model is used to describe the security
characteristics of the system and users.
• Through this security architecture can be easily
analyzed abstractly.
• Existence of Objects : which are viewed as the
consisting information,
• Subjects: are the agents, which act upon those
objects.
6
What does MAC do?
• MAC is the problem of appropriately governing
subjects access to objects according to their
security levels.
• The access of subjects to the objects should be
mediated in accordance.
• Subjects : Human Users or Processors
• Objects : Containers of the sensitive information.
7
BLP(Bell and LaPadula Model)
• Model for the Mandatory Security Model.
• Goal: Describes system with multilevel security
policy and operations in the system exactly.
• There are four access modes between subjects
and objects,
1.Read-Only 2.Append
3. Execute
4. Read- Write
8
Components:
System State: Each state in it is defined by
V=(B*M*F*H), B is the P(S*0*A)
M is the Access Control Matrix that can
access Si to an object Oj.
F – Functions of the Security level.
f s(s) – Maximal Security Level,
f c(s) – Current Security Level,
f o(o) – Security Level of object.
9
• State Transition: It is defined by a set of
operation rules, Decision (output) , Request (r)
Next State
p: RxV DxV
RxV – request state pairs, DxV – Decision State
pairs
D = {yes, no, error, ?}
• State. : A system (R, D, W, z) is a subset of (X,
Y, Z ) , and (x, y, z ) (R, D, W, z) iff (xt, yt, zt, zt1) eW, z) is a beginning state.
10
Axiom of Model:
11
Defining Security Policy
• When a process accesses a object, the subject
level would compared with the object level so
that MAC can determine whether the process
could access.
• Security Levels :
a. Hierarchical classification and
b. Nonhierarchical categories
12
• Hierarchical classification : composes a partially
ordered set of security levels, which can be coded
by binary.
Example : {top secret > secret > confidential >
unclassified).
• Non-Hierarchical classification: unordered set.
Example : Security UnixWare, it supports 256
classifications and 1024 Categories.
13
Security Levels:
Security Levels S1 and S2:
• S1 dominates S2 iff, (a). S2 ᴐ S1 (b).
Classifications (S1 ≥ S2)
• S1 equal to S2 iff, (a). Classifications(S1=S2)
(b). Categories (S1= S2)
• For all other Conditions, S1 is independent os
S2.
14
Security Policies:
• Mandatory Security Policy 1:
If and only if subject level dominates or equals to object level, a
subject can have Read or Execute access to an Object;
In the similar way it can have Write or Append access to object.
This policy accords with the BLP model discussed earlier.
• Mandatory Security Policy 2:
If and only if subject level dominates or equals to object level, a
subject can have Read or Execute access to an Object;
If subject level equals to object level, subject can have Write
access.
If subject level dominates object level, subject can have Append
access.
15
This policy leaves potential damage during covert
channel analysis. For example, a user with high-level can
enable or disable write access to an object with highlevel, but a process with low-level still can get
information about whether this file could be written
through a number of trial “Append”. So this policy is not
very rational.
• Mandatory Security Policy 3:
If and only if subject level dominates or equals to object level, a
subject can have Read or Execute access to an object;
If and only if Subject level equals to object level, a subject can have
Write or Append access to an object.
16
Defining Security Level
• Users security level limits the user’s ability to
read and change the information. This limits are
enforced by the TCB.
• A level alias is assigned for every level and given
by LID. It is the number system that uses to
identify a level.
• Four Classifications, four categories and eight
levels are predefined.
• This is mainly used to separate the Users from
Administrators.
17
Multi-Level Directories
18
• If a process’s multilevel directory mode is
virtual, then an access to a multilevel directory
by that process is modified by the kernel.
• The kernel changes the requested access to an
access to an effective directory within the
multilevel directory.
• If the process’s multilevel directory mode is real,
an access to a multilevel directory by that
process is not modified by the system.
• The process in real mode can see all effective
directories in the multilevel directory, subject to
MAC restrictions.
19
Conclusion:
• MAC is one of the key mechanism in security
operating system, is absolutely necessary to enhance
system security, and if there isn’t MAC the system
wouldn’t reach to high security grade.
• Through designing and implementing above security
policy and functions, adding MAC module in
UnixWare, system security is increased highly. We
test performance of some representative system
calls separately in UnixWare with MAC module and
in UnixWare without MAC module, it can be
concluded that system efficiency is not decreased
very much.
20
References:
• [l] Edmund Clarke and Jeannette Wing Formal
methods State of the art aid future directions.
Report of the ACM Workshop on Strategic
Directions in Computing Research, Formal
Methods Subgroup, August 1996 Available as
CMU Computer Science Technical Report CMUCS-96- 1 78
• [2] IS0 WG3 Evaluation Criteria for IT Security,
ISO/IEC Standard, 15408-1 1999, 1999
21
Thank you…!!