Trusted OS Research and Development[1]
- Including Korean cases -
Hyung Chan Kim, Wook Shin, R. S.
Ramakrishna
Security Research Group[2]
Dept. of Information and Communications
Gwangju Institue of Science and
Technology
Summary
These
days we encounter a surfeit of cyber threats to IT management. Security mechanisms
such as intrusion detection systems, fire walls, and virus scanners have been
developed to protect the IT community. Trusted Operating System (a.k.a. Secure
OS) is considered to be a fundamental countermeasure against security breaches
in an organization. The Trusted OS is an operating system which includes a
security kernel providing protection against diverse threats. It is usually based
on a logical model of access control. The resulting mandated information flow
amongst overall processes permits defense against unknown attacks. Some other protection
systems need specific signature of attacks.
Research and
development (R & D) of Trusted OS have been growing on since the 1970s. The
activities are growing with advances in operating systems, system security
technologies, and network infrastructure. The MAC (Mandatory Access Control)
and RBAC (Role-Based Access Control) have been the core models in the design of
security policy. The clear separation of enforcement mechanism and policy
application, such as founded in GFAC (Generalized Framework for Access Control)
and Flask, has dominated the architecture of Trusted OS. The emergence of Linux
OS as well as the fast growth of the Internet has led to widely adoptable
Trusted OS projects. The R & D pioneers have been the military wing of governments
in many countries in addition to universities and companies due to its (Trusted
OS) importance in national information security.
In
1.
Introduction
Workers on information security receive enormous
security advisories from mailing lists everyday. IT managers have adopted
several types of shield systems to protect their IT infrastructure from cyber
attacks. Widely adopted protection systems include intrusion detection systems
(IDS), firewalls, virus scanners, integrity checkers, malware inspectors, and
so on. We view the Trusted Operating System (TOS) as an operating system at the
core of computing environments: needless to say, many IT applications are
running on operating systems even at the time of writing. Researchers on
Trusted OS consider it to be a fundamental countermeasure against attacks.
The
principal strategy of Trusted OS is to provide enhanced access control models
beyond traditional schemes and the enhanced security is implemented at the
kernel level resulting in the security
kernel. Various logical models have been designed and enforced so that only
the security administrator can configure the security policy thereby achieving
Mandatory Access Control (MAC). An OS based on logical model of access control can
provide the ability to cope with unknown attacks while some other systems need
specific signature of attacks. The enforced logical model compels a given
access context to keep its mandated information flow as orchestrated by the security
administrator. Most researches have concentrated on the enforcement of security
policy: access control models, and enforcement architecture. The important
factors in implementation are: flexibility, negligible performance penalty
during enforcement.
The history
of Trusted OS goes way back to the nineteen seventies. It has evolved along
with operating systems and models of access control. Flask architecture [36] and
Generalized Framework for Access Control (GFAC) [37] noticeably influenced researchers
and engineers investigating enforcement architectures. These investigations
suggest general frameworks for the security server, (by which enhanced access
control model can be enforced,) as one subsystem of generic operating systems.
As for security models, Bell-LaPadula (BLP) model [38] and Role-Based Access
Control (RBAC) model [39] provide valuable insights for realizing the enforcement
of MAC in operating systems. Needless to say, there are many other architectures
and models to enhance the applicability of Trusted OS. With these
contributions, several implementations have appeared in both research and commercial
contexts. A remarkable feature is the availability of well-designed and open
source based Trusted OSs – such as SELinux [40], LIDS [60], and Grsecurity [61].
These have been adopted by many ordinary users and the IT industry.
In
In
this report we present research and developmental activities in Trusted
Operating Systems including efforts in
2.
The Concept of Trusted Operating Systems
2.1 Access Control
The concept of access control is best described
with the reference monitor model [Figure. 1]. The subject is defined as an
active entity which initiates access requests and operates on objects. Users or
autonomous agents can be subjects. The object is a passive entity which is a
target of an access. The examples of object are files, devices, money, or any
other resources that can be used by subjects. However, sometimes, a subject can
be an object and vice versa under the dynamic situation of accesses in a system
or an organization. Note that identifying a subject is under the assumption of
successful authentication of the subject. The reference monitor, which mediates
the access from a subject to an object, grants or denies access requests based
on the security relevant attributes of a subject and an object. The reference
monitor is a powerful tool for designing and analyzing system security under
the assumption of complete invocation for every access [41].
Figure 1: Reference Monitor Concept
There are three main types of access controls generally
discussed [42]: Discretionary Access Control (DAC), Mandatory Access Control (MAC),
and Role-Based Access Control (RBAC).
‚ Discretionary Access Control: DAC is
defined as a control method that enforces the specified mediation at the discretion
of a subject who is the owner of an object. Hence, DAC provides subjects with
the flexibility to protect their objects by setting DAC parameters as they see
fit. On the other hand, this flexibility can be the drawback in terms of
assurance of the flow of information. For example, someone, who has read access
of a data, can disseminate the contents of the data, though real owner do not
wants to do so.
‚ Mandatory Access Control: MAC is
defined as a control that enforces the specified mediation at the discretion of
a centralized administration facility. Thus MAC does not allow the subject to
modify the security parameters of their objects. This feature can give confidentiality
as well as integrity with the construction condition of MAC. However, MAC is
considered too rigid to be adopted in the commercial systems where the
movements of access entities can happen with high frequency.
‚ Role-Based Access Control: The main
characteristic of RBAC is that it does not directly associate a subject with an
object. Instead, by conceiving the role which represents job functions or
responsibilities in a system or an organization, RBAC greatly eases access
control administration. A conventional DAC or a MAC system usually involves
direct association between a subject and an object. If there are hundreds of
thousands of access entities – a possibility in large enterprises –
administrators of DAC or MAC system have difficulty in managing all the access
entities. A specific role gathers a set of necessary permissions – defined as
the cartesian product of the set of operations and the set of objects – in
order to perform a certain duty. Hence, if an administrator of the RBAC system
wants to make a subject perform a given duty, then the subject is simply
assigned an appropriate role.
The purpose of the access control is to limit the
actions or operations that a legitimate user of a computer system can perform.
To achieve this goal, a security administrator usually does follow the process.
First
he or she lists security requirements of the given system or the organization
and makes out the security policy for the listed requirements. The security
policy thus defines the set of requirements that must be met by an associated
system implementation or organization [8]. Eventually, the security policy
defines the functionality of a reference monitor. There are widely recognized
policies for military purpose and commercial purpose. Multi-Level Security
(MLS) [43] policy, suited for military purpose, is based on protecting
classified information. There are also policies suited for commercial purposes
such as
However,
a policy can be misunderstood since it is not formally defined. This may result
in serious problem, if one of the implementers misunderstands the policy
resulting in faulty access control systems. Thus the formulation of the
security policy is needed as a security model, so that all of the system implementers
can understand the given policy consistently. There are some models which
reflects multilevel security, based on lattice theory; Bell-LaPadula (BLP) model
[38] and Biba model [46]. Graham-Denning model [47], Harrison-Ruzzo-Ullman (HRU)
model [48], and Take-Grant systems [49] are all based on general theory of
computability [50].
Then,
the security policy is implemented with proper mechanisms. There are several
types of protection mechanism [8, 50]. The access matrix is a N x M matrix
which is constructed with N subjects in a row and M objects in a column [Figure
2]. The mechanism of access matrix is that the cell, where the subject and the
object met each other, specifies the access right. However, the access matrix
is generally sparse in the sense that most subjects do not have access rights
to most objects. There are two alternatives: Access Control List (ACL) and
Capability List (CL).
Figure 2: Access Control Matrix: ACL
and CL
ACL is the list representation of an access
matrix. The head node of ACLs is the object. For each object, it links the list
of allowable subjects with specific access rights [Figure. 2]. CL is also the list
representation of an access matrix. However, The CL's head node is a subject
and each head node of subjects links the list of objects with allowable access
rights for the subject. Hence the ACL and the CL are dual.
Permissions
based mechanism is widely used in general UNIX operating system in its file
system. This mechanism is designated to reflect DAC policies as the
administration of permissions for each object is responsible for the subject
which is the owner of the object. Label-based mechanism fits for implementing
MAC policies since it can label given objects competently and the labeling is
usually done by centralized administrator.
2.2 Trusted Operating Systems
The Trusted Operating Systems are the
security-enhanced operating systems. The term of trusted operating system has
been evolved since 1980s. The trusted operating systems classify the stored
information and provide security mechanisms for keeping secrecy, integrity and
availability of the information. The National Security Agency (NSA) of the
The Trusted
OSs aim to solve the problems resulted from the weakness of application-level
security solutions. In these days, threats to the computer systems are being
more serious. Hence, several security solutions such as intrusion detection
systems and firewalls have been adopted into business, educational, and private
environments to strengthen security of the computer systems. They are installed and operated on many
systems and provide security mechanisms that screen false information,
unauthorized accesses, intrusive trials, and so forth.
However,
the techniques bypassing security mechanisms in those security solutions have
also evolved [2, 3]. As a matter of fact, it may be the contradiction of
impenetrable shield and piercing-all spear. Various intrusion techniques have
appeared following the introduction of security applications to computer and
network systems. Hence, we have worried about possibility of bypassing and we
have patched the security applications repeatedly after the installation.
Figure 3: The layers in a computer
system.
The
weakness of current security solutions is originated from their structural
positions in computer systems. The structure of computer systems can be
simplified as shown in Figure 3. Operating systems provide such services as
system calls, commands, and application interface calls to the application
software. The vulnerable solutions
provide security mechanisms at the application-level based on the services from
the operating system layer. However,
dangerous processes can be also programmed and executed in the application level.
Then, it is not difficult to bypass
the application-level security mechanisms using the same services that the
operating system provides. To evade the watchdog, attack programs use API
functions or kernel services. It is hidden or replaced with the other legal one
that their signature information such as the function pointers or addresses are
stored in main memory.
Even
though the application-level security solutions are executed with more
privilege than user processes, they are not located at the bottleneck point
where they can observe and mediate all calls of user processes. Consequently,
their security mechanisms are not strong enough to enforce unavoidable
controls. To provide stronger security mechanism, they should be located at the
lower level than applications.
Private
firewalls and host-based intrusion detection systems are the host-based
security solutions. They are installed on any computer system and protect the
system from various intrusions. They have the security defect that was
previously discussed. It is not a problem of the host-based security solutions
only. Network-based security solutions are also installed on any computer or
embedded in network devices and they watch the interchanged information. Such
network-based solutions as network-based intrusion detection system and
firewalls are also vulnerable to the security threats. Packet watching
solutions are incapable of disguising packets and collaborating internal hosts.
It can be also broken down the computer system where network-based solution is
operated. If they cannot protect the intranet hosts, the network-based
solutions are surely regarded as being useless.
The
researches seeking more trusted systems are started from the weaknesses of
application-level security solutions. To solve the security problems more
fundamentally, the trusted operating systems should provide security mechanisms
at the kernel-level that is lower than the application-level. The security
controls must be enforced as a part of an operating system, and then provide
unavoidable control processes from the viewpoint of application-level processes.
Loscocco et al. [4] pointed out the security threats to modern computing environment
could not be solved without trusted operating systems. Additionally, he
emphasized the essence and importance of trusted operating systems with a
proverb: all security effort without trusted operating systems would result in “Fortress
built upon sand [5]".
At
the center of trusted operating system, there is a security kernel. Gollman [6]
described the concept of security kernel in the terms of the Trusted Computer
System Evaluation Criteria [7] that have been used as the evaluation guideline
of trusted operating systems. The related terms can be summarized as follows.
‚ The
trusted operating system is the
implementation of Trusted Computing Base.
‚ The
trusted computing base (TCB) is the
totality of computer system's protection mechanisms and it enforces a unified
security policy to guarantee confidentiality, integrity, and availability of
the system [6,7,8].
‚ The
security policy is the rules and
practices describing how sensitive information is processed, delivered, and protected
[9].
‚ The
reference monitor is a conceptual
model of access controls that mediates all accesses in a system. ‚ The security
kernel is the software and hardware elements that enforce access control. The
security kernel mediates all accesses of a system, and then only legitimate
accesses are performed in the system. The security kernel of trusted operating
systems implements the reference-monitoring concept of the trusted computing
base.
In a
word, the security kernel is the core of trusted operating system and they are
the implementation of reference monitor and trusted computing base,
respectively.
|
Conceptual
level |
Implementation
level |
|
Reference
Monitoring |
Access
Control |
|
Reference
Monitor |
Security
Kernel |
|
Trusted
Computing Base |
Trusted
Operating System (Security sub-system) |
The main security service of trusted operating
system is the access control of security kernel.
3.
Efforts on the Trusted OS development
Though there are many efforts on the development
of Trusted OS from 1970s. We give recent active cases here.
3.1 RSBAC
RSBAC (Rule Set Based Access Control) is a
kernel patch for enhancement of Linux security [62, 63]. Its architecture is
based on Generalized Framework for Access Control (GFAC) to support multiple
policies [Figure 4]. GFAC framework is consists of Access Control Information
(ACI), Access Control Enforcement Facility (AEF), and Access Control Decision
Facility (ADF). The ACI module manages security attributes of subjects (process,
user) and objects. ACIs for users and files are stored in secondary storage as
well as in memory so as to recover in boot time. AEF is implemented in security-relevant
system calls wherein rsbac_adf_request
function is embedded to mediate access request to ADF module. Therefore a given
access can be granted or denied on the decision of ADF module beyond the
decision of DAC. RSBAC defines 35 request types and each type is related with
appropriate system calls and target types. For example, READ_OPEN request to
read some resources are related with open, shmat, msgrcv, recv, recvform, and
recvmsg functions in kernel and corresponding target attributes can be file,
fifo, device, and ipc.
Figure 4: RSBAC system architecture
RSBAC includes multiple policy modules in ADF
and a final decision of combination of those policies is accorded by a
metapolicy which deny a given access if at least one module denies.
The
supported policies are as follow:
‚
MAC:
‚ FC
(Functional Control): A simple role based model.
‚ SIM
(Security Information Modification): Only security administrators can modify
security information which is specifically labeled data.
‚ PM
(Privacy Model): Task-based privacy model. Subjects can only access objects by performing
specific task.
‚ MS
(Malware Scanner): On-access scan (by EXECUTE, open-ADF request for file,
read-ADF for socket) of data to inspect whether the data contains malcode or
not.
‚ FF
(File Flags): Labeling files with certain flags. The labels are checked
whenever access is requested for certain purpose. For example, no_execute label
prohibits the execution of a labeled file.
‚ RC
(Role Compatibility) Model: Roles can be codified as sets of access permissions
to object types (FILE, DIR, DEV, IPC, SCD, PROCESS). A process can access to objects
with certain access mode if the process performing appropriate role. It is similar
with RBAC and Type Enforcement [64].
‚
AUTH: A capability is a set of users. A process can change its user ID (setuid)
to another UIDs bounded by capability.
‚ ACL
(Access Control List): An ACL entry consists of subject and access mode. For an
object, a set of ACL entries can be defined. A process, as a subject, can
access to an object if the right is specified in ACL associated with that
object. Role Compatibility is considered in RSBAC.
Figure 5: SELinux Architecture (Flask architecture and its components)
3.2 SELinux
SELinux (Security-Enhanced Linux) [40] was developed
by National Security Agency (NSA),
As
for access control models, SELinux provides RBAC and TE (Type Enforcement). MLS
is also supplied though it has been in experimental status. A role represents
user’s allowable actions. The actions are described by TE policy: a type is
specified for each subject and object – it is slightly different from original
TE [64] in which a subject is specified with the concept of domain – so that relevant
subjects and objects can be managed together by the manipulation of type achieving
fine-grained access control. A Security Context is then specified by policy configuration
for subject with user identity, role, and type. For example, a running process,
owner is a ordinary user ‘chan’ by spawning the bash shell, can be considered
as a security context chan:user_r:bash_t. As for object, a certain executable
file can be labeled as system_u:system_r:prog_exec_t for its security context. Subsequently
the configuration can allow the users’ execution of that file by specifying ‘allow
bash_t prog_exec_t:process execute;’ which means that a subject type bash_t can
execute a file which is typed with prog_exec_t. In the real access decision, a
security context is mapped to an integer value called as security identifier
(SID).
SELinux
provides substantial policy language for RBAC and TE configuration. There are efforts
to analyze the SELinux policy configuration with formal method and language
based approach [66].
The
Flask architecture clearly divides logical access control policy and enforcement
facility so as to enforce several types of access control. Object Manager is implanted
in the kernel subsystem to catch system actions ignited from the file system or
network subsystem, Object Manager thus acts as an AEF. Moreover, Security
Server decides whether a given access request, presented by Object Manager, has
to be granted or denied as a role of ADF. Therefore, Object Manager can block
or pass the given access by the decision of Security Server [Figure 5]. For the
consideration of performance overhead, Access Vector Cache is included to
reduce performance penalty by the enhanced access control. This kind of clear
discrimination between access decision and enforcement gives an ability to
change a currently enforcing security policy to the others in system runtime.
SELinux
is implemented on Linux Security Module (LSM) [68]. The LSM provides a
lightweight, general purpose framework for access control [67] considered as
generalized AEF framework. It aims to harmonize other works of security kernel
patch supporting enhanced access control such as RSBAC [62], Grsecurity [61]
and LIDS [60] which are once ported on LSM. However, there are some counter opinions
of using LSM in [61, 62].
3.3 REMUS
Researchers of REMUS (REference Monitor for UNIX
Systems) [69, 70] designed their access control mechanism based on a detailed
analysis and empirical classification of the UNIX (LINUX) system calls. Their
main concerns are on that how the buffer and heap overflow attacks causes and
how the privileged tasks such as setuid and root privileged daemon can be
harmed in a system. Regarding these, they analyzed Linux system calls that may
give severe influences on security. The system call is categorized according to
functionality [Table 1] and also categorized by threat level [Table 2] which
describes the degree of hazard.
Table
1: System Call Categories
|
Group |
Functionality |
|
I |
File system,
devices |
|
II |
Process
management |
|
III |
Module
management |
|
IV |
Memory
management |
|
V |
Time and
timers |
|
VI |
Communication |
|
VII |
System info |
|
VIII |
Reserved |
|
IX |
Not
implemented |
Table 2: Threat Level Classification
|
Threat
Level |
Description |
|
1 2 3 4 |
Allows
full control of the system Used
for a denial of service attack Used
for subverting the invoking process Harmless |
The reference monitor design of REMUS includes
the reference function and the authorization function. The reference function
is considered as ADF so as to decide whether requested systems call can be
granted or not, based on access control database (ACD). The authorization
function reflects the modification of access control rules of ACD. The ACD is
encoded as conceptual access control rules with process, system call, and
access mode descriptions. ACD contains rules to control with reference monitor
for each system call. For instance, execve_acd access control data structure is
defined to control execve system call and contains admitted list of executable
program (inode), and log of unauthorized attempts. Over 200 control points in
Linux kernel source, operation is controlled in accordance with ACD. Each control
point is patched with invocation of check_rootproc function which checks root
process and refers ACD. The REMUS patch inserts sys_aclm system call to manage
ACD.
Implementation
of REMUS is done with kernel patch type as well as module type (LKM) and
performance tests are conducted for each case. They conducted detailed analysis
on the cache effect of file name which is related with open system call, i.e.
with and without the cache to see overhead of REMUS more closely. They
recovered that 3% and 18 % critical system call monitoring overhead in patch
based and module based implementation respectively.
3.4 grsecurity
The aims of Linux kernel patch presented by grsecurity
[61, 71, 72] are on diminishing performance hit, supporting scalable access
entities, and lessening configuration burden. Mainly they have offered
restriction on transition to root privileges by strengthening the chroot system
call: they restricted security relevant signals from outside of chroot and
forbid mount, pivot_root, double chroot, and so on.
As
for enhanced access control, RBAC is implemented in grsecurity. Roles can be
defined in three ways: user, group, and special roles. User and group role are
associated with uid and gid respectively. Special role can be codified to
define some other responsibilities tailored by security administrator. Particularly
IP-based role is supported so that a host from specified IP address can use that
specific role. In grsecurity, role hierarchy is predefined as following order:
special role, user role, group role, and default role. If a user from a certain
host, not specified in IP list, tries to be assigned to a special role, then he
or she falls in that other until applicable role is appeared. Unlike that
SELinux have deprecated role transition, grsecurity supports role transition
with role transition table.
Interesting
feature of grsecurity is on its learning system which intelligently learning a
given system and produce policies according to the learning. It is quite
useful, if well implemented, because specific policy configuration for Linux OS
containing many user programs and service daemons can not be analyzed easily
and it is work of labor. While the learning, kernel sent relevant logs to user
space. The learning log analyzer and rule set generator are involved to achieve
the task which is done with graph based reduction algorithm with the log.
The
work of PaX [73] is included in grsecurity kernel patch. PaX gives ability to shield
the runtime environment of program execution by supporting non-executable
memory pages and full address space layout randomization (ASLR). Conventional
buffer overflow attack tries to place its shell code in data segment. However,
PaX-SEGMEXEC causes a page fault if instruction patch attempts to address data segment.
ASLR makes difficult in guessing return address which is crucial in program
runtime attack.
They
showed that their performance with PaX in MySQL benchmark as a real life
example in which 13% overhead and predicted 3% to 20% overhead over different
type of memory access patterns test by test.
3.5 LIDS
Linux Intrusion Detection System (LIDS) [60, 74]
has been implemented to support MAC as well as other control mechanisms on
file, device, and network I/O. The fundamental aim of LIDS is file system
protection. It adds inode list which contains protected file information in
Virtual File System (VFS) layer and supports restriction on reading/writing of
file (directory), appending only file (directory), exceptional taking off
protection from file (directory), and mounting/unmouting of filesystem.
LIDS
offers process protection by making a process invisible from process list and
unkillable by anybody including root. Hidden process is implemented with
modifying sys_execve system call and functions related to proc filesystem where
process information is recorded. Unkillable function is simply implemented in
sys_kill system call.
In
recent we have met attacks against Linux kernel module such as rootkit. LIDS
offer kernel sealing against these threats. If the sealing is enabled, necessary
kernel modules can be loaded only in system bootup. After a kernel is sealed,
there is no way to insert any additional modules by anybody. Also, security
configuration such as capability setting is disabled, thus security administrator
has to configure appropriately before the sealing. At the reconfiguration of
system, password authentication is required.
The
rich set of network control is achieved in LIDS. Rules for firewalling and routing
can be set. Control over promiscuous mode of network interface is useful in
preventing packet sniffering (wiretapping) abuse. In TCP stack, port scan
detection routine is also added.
Recently
LIDS started to support Trusted Domain Enforcement (TDE) [75] which takes
sandbox approach to cope with privileged process behaving abnormally. They
motivated from the fact that even a process is privileged by security
configuration, in some case they can behave badly by illegal input of attacker.
By compartmentalizing process in some extent, LIDS can minimize the effect of abnormal
behavior.
3.6 MEDUSA DS9
MEDSUA DS9 implements security enhancement with
ZP Security Framework [76, 77]. They proposed Virtual Space (VS) model as their
access control model. The notion of VS model is that if there is at least one common
virtual space between subject and object with specific access type (right), then
the access is granted. They showed that how their security policy can be
multiply existed with logical AND, and OR. Translation VS model into ACL, CL,
and MLS model are also presented.
3.7 Domain and Type Enforcement
Domain and Type Enforcement (DTE) [64, 80, 81]
is an extension of Type Enforcement which is table based mandatory access
control scheme. Domain and type represent abstraction of subject and object
respectively. Two tables are involved: Domain Definition Table (DDT) and Domain
Interaction Table (DIT). DDT is similar with traditional access control matrix
and represents domain in its row and type in its column. The cell placed in
specific cross between domain and type specifies access modes. When runtime
access between subject and object is triggered, table lookup is performed. DIT
gives rights among process. For example, DIT table lookup is done, when subject
creates another subject such as process creation, or signaling. However, real
implementation of DTE does not use concrete table. Instead of it, high level
DTE language is defined and gives many advantages in security administration. Especially,
implicit typing lessens the burden of labeling each access entities one by one.
DTE does not label security attributes on each object and subject directly
(such as in low level file system) so that physical scanning of media can be
avoided whenever policy have to be reviewed or analyzed. More importantly this
approach gives benefit on supporting independence on low level file system
which enables adoption of heterogeneous file systems without direct
modification of each file system type.
Table
3 shows an example DTE policy for passwd [81]. Some files related to passwd
application is assigned to passwd_t type as objects. As for a subject, domain
passwd_d is defined in that it is process of /etc/bin/dtpasswd and have create,
read, write, and traversal of directory privileges on passwd_t type.
Recent
implementation of DTE in Linux is done on LSM [78, 79].
Table 3: An example of DTE Policy for
Passwd
|
type passwd_t; domain passwd_d = (/usr/bin/dtpasswd), (crwd->passwd_t),
(rwd->readable_t, writable_t), (rxd->binaries_t), (rd->generic_t); assign –s passwd_t /etc/{master.passwd,
spwd.db, pwd.db, passwd}; |
3.8 Others[3]
Vendors also have activated its efforts on TOS development.
IBM, Sun Microsystems, HP, and other major OS vendors have extended their OS
supporting enhanced access control mechanisms in their products. Recently Linux
vendors such as RedHat and SuSe also emerged into the development and their
TOSs are evaluated by Common Criterion. In
4.
Trusted OS developments in Korea
In
This
chapter presents generally known Trusted OS developmental activities in
4.1 L4Linux-MLS and RedOwl SecuOS
Researchers of
Figure 6: L4Linux
Architecture and L4Linux-MLS Architecture
Figure 7: IPC via L4 microkernel in
Authentication and Access Control
The security servers consist of access control
server, authentication server, and audit server. In access control server, modified
BLP (Bell-Lapadula) model is embodied with 5 security levels (Top Secret, Secret,
Classified, Restricted, Unclassified), and 24 categories. They write-up
property is forbidden from the original BLP model [23]. Categories are
information to enforce need-to-know rules. Security labels are encoded in Linux
ext2 file systems and process subsystem respectively. Authentication and access
request triggered from subject is delivered to security server components
through L4 microkernel IPC facility [Figure 7]. If a access request is given to
access control server via IPC-send, then access control server returns
appropriate decision based on subject’s uid, object’s clearance, category, and
type of operation. In their later prototype, security interface was provided [Table
4]. MLS-aware utilities are also implemented using security interface: mlswho,
mlsps, mlspstree, mlsw, and the like.
Table 4: Principal security system call and its functionality
|
System call |
Function |
|
ps_crw (cl, ca) |
Assign or verify subject label from process |
|
mls_rw |
Assign or verify object label |
|
mls_who (pid, cl, ca) |
Show user’s clearance and category |
|
ca_to_string |
Convert bit-encoded category to string |
Besides
access control models, they emerged detection mechanism against buffer overflow
attacks in their kernel implementation since the buffer overflow attack is the
most realized threats in generic UNIX/LINUX operating systems. The simple mechanism
was equipped in sys_execve(): restricting un-ordinarily long buffer size and
checking NOP operation: NOP operation (0x90) is generally used to enlarge the
probability of attack.
In
respect of privacy, the encryption file system is supported with SEED block
cipher algorithm which is a part of Korean standards [24]. File objects are encrypted
with associated MLS classification level information strengthening its
security.
Unlike
the conventional log systems, they used relational database system (MySQL) as
log systems. The kernelized database management functions are implemented
thereby recording access control history. High level log reduction can be
possible with the access log in database systems compared to simple log
systems. In actual implementation, they made 30 classification of audit trail
table to security analysis.
They
started formal Trusted OS projects from 1998 [25] and researchers have been contributed
to commercial version of Trusted OS: RedOwl SecuOS with TSonNet Co., Ltd. [13].
Since RedOwl SecuOS aims at commercial market it includes various
administrative facilities such as GUI-based unified security management. RedOwl
SecuOS V4.0 for Solaris 9 systems is evaluated as EAL3+ on Common Criteria conducted
by KISA in Feb 2005.
Figure 8: SecuROS system (Composition
of Trusted OS functionality)
4.2 SecuROS
SecuROS is trusted operating
systems from ETRI [17]. They have employed DAC, MAC, and RBAC as their access
control [Figure 8] to enhance security of FreeBSD operating systems.
They provided Access Control List (ACL) for DAC mechanism. ACL is
compatible with existing FreeBSD OS and POSIX1003.1e. For enforcing MAC, they
implemented multi-level security (MLS) facility in their system with modified ss(simple
security)-property and *(star)-property which are core of BLP (Bell-Lapadula)
models. Their modification of BLP is that reading is permitted on equal or down
level but writing is only permitted on the same level. RBAC is realized in
their system by implementing core RBAC component and separation of duty
component that are defined in NIST RBAC standard [21]. In their RBAC
implementation, 16 roles can be coded for a given policy and the roles can be
flexibly assigned and revoked with static structure and generation number
scheme. The limitation of 16 roles comes from static biding its attribute structure
to inode in the file system.
The
composition of access control models take conservative approach: if at least
one access control modules denies on its decision, then resulting decision also
returns denial regardless of decisions of remaining modules.
Interesting
features of SecuROS are on the encryption file systems [19] and Trusted Channel
in Trusted OS environment [18, 20]. They suggested automatic encryption method reflecting
currently enforcing access control policies. Unlike the conventional encryption
file systems, their mechanism (AEFS: Access Control based Encryption File system)
[Figure 9] supports simplified key management based on MAC security level
information. It is implemented on FreeBSD VFS (Virtual File System) layer and has
two functional parts, i.e. Encryption Decision Part (EDP) and Data Encryption
Part (DEP), respectively. EDP refers access control modules to judge whether a
given file has to be encrypted or not. If the encryption is required then DEP
receives a request from EDP.
Figure 9: AEFS with Access Control
Modules and Its Key Initialization
Secure Operating System Trusted Channel (SOSTC)
[18] was proposed to support a logically single secure computing environment
when multiple Trusted OSs are involved together, replacing IPSec which is not
suitable for delivery security information of Trusted OS. SOSTC consists of
STIP (SOSTC Initialization Part) for key initialization at boot time, STDP
(SOSTC Decision Part) for decision of type of packets to be injected in trusted
channel, STPP (SOSTC Protection Part) for execution of SOSTC process in which
proper packetization step is included with encryption processes. In their
papers, both AEFS and SOSTC show small performance overhead.
4.3 SecuveTOS
SecuveTOS has been developed by Secuve Co., Ltd.
[14, 26, 27] since 2000[5].
The main model of access of SecuveTOS is RBAC. A user is assigned to
appropriate roles and MAC over more than 23 system calls are achieved in the
following fashion: {Grant = Op(File,
Process, System, Role)}.
One distinguished feature of SecuveTOS is on its
authentication mechanism. They implemented PKI-based Trusted OS authentication
facility with X.509 v3 standards. Their PKI –based authentication can be
cooperated with Korea Financial Telecommunications
& Clearings Institute (KFTC) and other 5 public Certification Authorities (CA) in
As it is commercial version of Trusted OS, it
includes many features other than access control: cooperated system attack
detection with IDS, security administration with several tools (GUI-based ACL
editor, policy simulation, performance tuning. etc), and encryption file
systems.
SecuveTOS is most successful in Trusted OS market share
in
4.3 SeeCure OS
SeeCure OS (CSRL system) [28, 29, 30, 31, 32, 33]
has been a research prototype of Security Research Group (SeeCure), Gwangju
Institue of Science and Technology (GIST) since 2001. The major concentration
of SeeCure OS is themis kernel [Figure 10] in which enhanced models of access
control are applied: E-BLP, E-RBAC, and C-RBAC [Figure 11].
Figure 10: Trusted OS Architecture (Themis
Kernel)
E-BLP [29] is an extended model of BLP model. It
is proposed to prevent the disclosure and integrity threat while still
supporting some degree of flexibility compared to conventional BLP model, which
is too rigid to be adopted in commercial systems. In E-BLP model, processes are
grouped into two subdivisions, common for normal user process to be enforced
under MLS policy and public for system daemons (httpd, and ftpd) to be enforced
in less restrictive manner. The executions of all processes are controlled by
Dynamic Reliability Check (DRC) against unpredicted behavior.
E-RBAC
(Extended Role Based Access Control, and a.k.a. Role-Behavior Based Access
Control) [28, 32] exploits the limitation of conventional access control
paradigm: no relation information is involved amongst consecutive access
events. E-RBAC extends traditional RBAC model to include the functionality of procedural
restrictions. Therefore, a role can be codified with a set of behaviors instead
of tuples of operation and object. Negative description of procedure is also
possible to restrict the malicious attack as usual Intrusion Detection Systems
do. Colured Petri Net Based Model [31] also suggested ensuring the safety property
of E-RBAC model.
To
address the cooperation problems of multiple Trusted OSs in distributed
environments, C-RBAC (Collaborative Role-Based Access Control) has been
suggested [30]. C-RBAC introduces the concept of multi-domain security which
images the distributed domain of each Trusted OS.
Beyond
the adoption of enhanced access control, SeeCure OS includes Hybrid type of IDS
in kernel level [33]. It introduces Intrusion Prediction Database which
consists of Anomaly Behavior segments which are a set of WINDOWSs to detect
unknown behavior with high probability. It also use misuse detection partially
thereby achieving hybrid type of intrusion detection.
Figure 11: E-RBAC (RBBAC) and C-RBAC
model
The implementation on Embedded OS was also made
[35]. E-RBAC model was implemented on uClinux considering unified task of both
access control and intrusion detection with negligible performance overhead which
is important factor in Embedded OS.
4.4 Others
Table 5 shows commercial
products of Trusted OS developed since 1999. Each company includes several
versions of Trusted OS.
Table 5: Commercial products of
Trusted OS (except Secuve and TSonNet)
|
Company |
Product Name |
Access Control |
Etc |
|
SecuBrain [51] |
Hizard |
RBAC |
LKM, Antihacking |
|
Oullim [52] |
SECUREWORKS@Server |
RBAC |
Multi Layered
Security |
|
RedGate [53] |
|
RBAC, MLS |
IPS, Antihacking |
|
TMAX Soft [54] |
Skykeeper OS |
RBAC, MAC |
ESM |
|
LSData [55] |
BizOS |
MAC |
Antihacking |
|
KTIS [56] |
LastAid |
MAC, |
Rule-set based
Access Control |
|
KEXIN Systems
[57] |
Hwarang
Safeguard |
RBAC |
Auth.
Antihacking |
|
LG Nsys [58] |
Safezone Trust |
MAC |
Self-protection |
|
NileSoft [59] |
SecuGuard NSL,
ENTRUS |
MAC |
|
|
Cyber Research* |
Cyros for Linux |
MAC, RBAC |
|
|
Scuve* |
AccessCOPS |
MAC |
|
*: currently out
of market
5.
Concluding Remarks
This report has given the concept of Trusted Operating
Systems in view of enforcement of enhanced access control mechanisms. Trusted
Operating Systems are less known compared to intrusion detection systems or firewalls.
However, there are many evidences recovering that Trusted OS has ability to
mitigate unknown attacks and considered as a last line of defense.
There
are recent active efforts on the development of TOS. We briefly reviewed
SELinux, RSBAC, DTE Linux, REMUS, MEDUSA DS9, and Grsecurity. Each project has
supported upgraded security mostly on its access control mechanisms. Some
common goal is on the enforcement of variable security policies and its minimal
performance hit. In case of SELinux, it is shipped on several Linux
distributions getting worldwide adoption by ordinary users. With the enhancement
of Operating Systems, it will also keep its developmental activities.
Researchers
and engineers in
Now
we are facing new paradigms of computing environments: ubiquitous or pervasive
computing. Home network and sensor network will require stable, trusted middleware
operating systems. There are already small movements of porting enhanced access
control subsystems to some embedded systems. If we continue researches on those
area as well as theoretical study on model of access controls, it will support
sound base systems to those emerging computing environments.
References
[1]
T. Mills, ``Trusted Operating Systems", Carnegie Mellon Software
Engineering Institute, 1997. http://www.sei.cmu.edu/str/descriptions/trusted\_body.html
[2]
T. Ptacek and T. Newsham, Insertion, Evasion, and Denial of Service: Eluding
Network Intrusion Detection, 1998.
[3]
rattle, ``Using Process Infection to Bypass Windows Software Firewalls",
Phrack, Vol. 0x0b, Issue 0x3e, 2004. http://www.phrack.org/phrack/62
[4]
P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner,
and J. F. Farrell, “The Inevitability of Failure: The Flawed Assumption of
Security in Modern Computing Environments", In Proceedings of the 21st
National Information Systems Security Conference, pages 303-314, October 1998.
[5]
D. Baker, Fortresses built upon sand, In Proceedings of the New Security
Paradigms Workshop, 1996.
[6]
D. Gollmann, Computer Security, John Wiley & SONS, 1999.
[7]
[8]
E. G. Amoroso, Fundamentals of Computer Security Technology, AT\&T
[9]
M. D. Abrams, S. Jajodia, and H. J. Podell, “Information Security An Integrated
Collection of Essays", IEEE Computer Society Press, Los Alamitos (CA),
1995.
[10]
KISA, Information Security in Computer Networks - Access Control Technologies,
Dec. 1996.
[11]
H. B. Kim, K. H. Oh, H. J. Kwon, J. D. Koo, K. Y. Hong, “OS Security Technology
Tendency,” 韓國情報保護學會論文誌, Vol. 8, No.
2, pp. 64-84, 1998.
[12]
T. K. Park, “Tendency of Research and Development of Secure Linux,” 韓國情報保護學會誌, Vol. 13, No. 4, pp.
37-48, 2003.
[13]
TSonNet Co. Ltd., http://www.tsonnet.co.kr/etc/english.html
[14]
Secuve Co. Ltd., http://www.secuve.com/eng/
[15]
Korea Information Security Agency (KISA), http://www.kisa.or.kr/english/
[16]
Electronics & Telecommunications Research Institute (ETRI), http://www.etri.re.kr/e_etri/index.php
[17]
J. G. Ko, J. N. Kim, K. I. Jeong, “Access Control for Secure FreeBSD Operating
System,” Proc. of WISA 2001, The Second International Workshop on Information
Security Applications, pp.247-254, 2001.
[18]
J. D. Lim, J. S. Yu, J. N. Kim, “A study of the method of providing secure
network channel among secure OSs,” Proceedings of the 1st international symposium
on Information and communication technologies, pp. 345-350, Dublin, Ireland,
2003.
[19]
J. D. Lim, J. S. Yu, J. N. Kim, “Automatic Encryption Method within Kernel
Level using Various Access Control Policy in UNIX system,” 韓國情報處理學會 論文誌 C, Vol. 10,
No. 4, pp. 387-396, 2003.
[20]
J. S. Yu, J. D. Lim, J H. Nah, S. W. Sohn, “The Design and Implementation of
Module supporting Trusted Channel in Secure Operating System Environment,” 韓國情報保護學會論文誌, Vol. 14, No. 3, pp.
3-13, 2004.
[21]
David F. Ferraiolo,
[22]
C. W. Lee, H. H. Kim, T. K. Park, “Implementation of L4-MLS with
Security Servers,” Proc. of Joint Workshop on Information Security and
Cryptology 2000,
[23]
Tae Kyou Park, Yeon Ho Im, “Implementation of Secure Linux OS based on Kernel,”
韓國情報保護學會論文誌, Vol. 11, No.
4, pp. 33-43, 2001.
[24]
KISA, Block Cipher Algorithm: SEED, http://www.kisa.or.kr/seed/seed_eng.html
[25]
Info Sec. Lab,
[26]
Y. C. Park, “TOS 2.5.50 Proposal,” Secuve, 2004.
[27]
K. Y. Hong et al., “Intelligent Multilevel Information Protection System based
on Secure OS,” 韓國情報處理學會誌, Vol 10., No 2., pp 58-63, 2003.
[28]
W. Shin, D. I. Lee, H. C. Kim, J. M. Kang, J. S. Lee, "Extended Role Based
Access Control and Procedural Restrictions for Secure Operating Systems,"
LNCS 2971 Information Security and Cryptology - ICISC 2003, 6, pp. 197-210,
2003.
[29]
J. M. Kang, W. Shin, C. G. Park, D. I. Lee, "Extended BLP Security Model
Based on Process Reliability for Secure Linux Kernel ," Proceedings 2001
IEEE Pacific Rim International Symposium on Dependable Computing, pp. 299-303,
2001.
[30]
H. C. Kim, R.S. Ramakrishna, K. Sakurai, "A Collaborative Role-Based
Access Control for Trusted Operating Systems in Distributed Environment,"
IEICE Trans. on Fundamentals, Vol.E88-A, No.1, pp. 270-279, 2005.
[31]
W. Shin, J. G. Lee, H. K. Kim, K. Sakurai, "Procedural constraints in the
extended RBAC and the Coloured Petri Net modeling ," IEICE Trans. on Fundamentals of Electronics,
Communications and Computer Sciences, vol. E88-A, no. 1, pp. 327-330,
2005.
[32]
W. SHIN,J. Y. PARK, D. I. LEE, “Extended
Role Based Access Control with Procedural Constraints for Trusted Operating
Systems,” IEICE Trans. on Information and Systems, Vol.E88-D No.3
pp.619-627 2005.
[33]
K. W. Ko, K. T. Kim, H. C. Kim, R.S. Ramakrishna, K. Sakurai, "A Real-Time
Intrusion Detection Mechanism based on Anomaly Behavior Segments," In Proc. of 2005 Symposium on Cryptography
and Information Security (SCIS2005), Vol. IV of IV, pp. 1897-1902, 2005.
[34]
S. Forrest et al., “A Sense of Self for UNIX processes”, IEEE Symp. on Security
and Privacy, 1996.
[35]
W. Shin and H. K. Kim, “A Simple Implementation and Performance Evaluation of
the Extended-Role Based Access Control,” WSEAS Transactions on Information
Science and Applications, vol. 2, no. 1, pp. 215-219, 2005.
[36]
Ray Spencer, Stephen Smalley, Peter Loscocco, Mike Hibler, David Andersen, and
Jay Lepreau. The Flask Security Architecture: System Support for Diverse
Security Policies. In Proceedings of the Eighth USENIX Security Symposium,
pages 123-139, August 1999.
[37]
Marshall D. Abrams, Leonard J. LaPadula, Kenneth W. Eggers, and Ingrid M.
Olson. A generalized framework for access control: An informal description. In
Proceedings of the 13th National Computer Security Conference, pages 135-143,
October 1990.
[38]
D.
[39]
D. Ferraiolo, J. Cugini, and R. Kuhn, ``Role Based Access Control: Features and
Motivations,'' In Proc. of Computer Security Applications Conference, IEEE Computer
Society Press, 1995.
[40]
The SELinux project, http://selinux.nsa.gov
[41]
Irvine, C.E., "The Reference Monitor Concept as a Unifying Principle in
Computer Security Education," In Proceedings of First World Conference on
Information Security Education, IFIP TC11 WC 11.8, pp. 27-37, Jun. 1999.
[42]
[43]
D. Denning, "A Lattice Model of Secure Information Flow,"
Communications of ACM, Vol. 19, No. 5, pp. 236-243, 1976.
[44]
D.F.C.Brewer, and M.J.Nash.The, "The Chinese Wall Security Policy," In
Proceedings of IEEE Symposium on Security \& Privacy, pp. 206-214, 1989.
[45]
D. Clark, and D. Wilson, "A Comparison of Commercial and Military Computer
Security Policies," In Proceedings of IEEE Symposium on Security &
Privacy, pp. 184-194, 1987.
[46]
K. Biba, "Integrity Considerations for Secure Computer Systems,"
[47]
GS Graham, and PJ Denning, "Protection-principles and practices," In
Proceedings AFIPS Spring Joint Computer Conference, Vol. 40, pp. 417-429, 1972.
[48]
Michael A. Harrison, Walter L. Ruzzo, and Jeffrey D. Ullman, "Protection
in Operating Systems," Communications of the ACM ,Vol. 19, No. 8, pp.
461-471, 1976.
[49]
Anita Jones, "Protection Mechanism Models: Their Usefulness," In
Foundations of Secure Computation, pp. 237-252, 1978.
[50]
Charles P. Pfleeger, "Security Computing," 2nd. Edition, Prentice-Hall
PTR, 1997.
[51]
Secubrain Co. Ltd., http://www.secubrain.com
[52]
OULLIM Information Technology Inc., http://www.oullim.co.kr/
[53]
RedGate Co. Ltd., http://www.redgate.co.kr/
[54]
TMAX Soft Co. Ltd., http://www.tmax.co.kr/
[55]
LSData, http://www.linuxsecurity.co.kr
[56]
KTIS, http://www.lastaid.com/
[57]
KEXIN systems, http://www.kexin.co.kr
[58]
LG Nsys, http://www.safezoneips.com/
[59]
NileSoft, http://www.nilesoft.co.kr
[60]
LIDS, http://lids.org
[61]
GRSecurity, http://grsecurity.org
[62]
RSBAC, http://www.rsbac.org
[63]
Amon Ott, Simone Fischer-Hubner, “The Rule Set Based Access Control (RSBAC)
Framework for Linux,”
[64]
L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, S. A. Haghighat, “Practical
Domain and Type Enforcement for UNIX,” Proceedings of the 1995 IEEE Symposium
on Security and Privacy, 1995.
[65]
Peter Loscocco, and Stephen Smalley, “Integrating Flexible Support for Security
Policies into the Linux Operating System,'' In Proc. of the FREENIX Track: 2001
USENIX Annual Technical Conference (FREENIX'01), Jun.2001.
[66]
Giorgio Zanin, Luigi Vincenzo Mancini, “Towards a formal model for security
policies specification and validation in the selinux system,” Proceedings of
the ninth ACM symposium on Access control models and technologies, Pages: 136 –
145, 2004.
[67]
Linux Security Module, http://lsm.immunix.org/
[68]
Stephen Smalley, Chris Vance, and Wayne Salamon, “Implementing SELinux as a
Linux Security Module,” December 2001 (Revised in Feb. 2005).
[69]
Massimo Bernashi, Emanyele Gabrielli, Luigi V. Mancini, “REMUS: A
Security-Enhanced Operating System,” ACM Trans. on Info. & Syst. Sec., Vol
5, No 1, pp. 36-61, 2002.
[70]
REMUS project: http://twiki.dsi.uniroma1.it/twiki/view/Remus/WebHome
[71]
Brad Spengler, “Increasing Performance and Granularity in Role-Based Access
Control Systems: A case study in GRSecurity,” http://www.grsecurity.net/papers.php
[72]
Brad Spengler, “GRSECURITY ACL DOCUMENT V1.5,” http://www.grsecurity.net/papers.php
[73]
PaX, http://pax.grsecurity.net/
[74]
Xie Huagang, “LIDS Hacking HowTo,” v1.0, 29 March 2000.
[75]
Yusuf Wilajati Purna, “Trusted Domain Enforcment (TDE): An Introduction,” Sep.
2004.
[76]
MEDUSA DS9 Project, http://medusa.fornax.sk/
[77]
Marek Zelem and
[78]
Domain and Type Enforcement for LINUX, http://www.cs.wm.edu/~hallyn/dte/
[79]
Serge
[80]
Lee Badger et al., “A Domain and Type Enforcement UNIX prototype,” In proc. of
the fifth USENIX UNIX Security Symposium, 1995.
[81]
Kenneth M. Walker et al., “Confining Root Programs with Domain and Type
Enforcement (DTE),” In proc. of the sixth USENIX UNIX Security Symposium, 1996.
[82]
Argus Systems (Innovative Security Systems, Inc.) , http://www.argus-systems.com/
[83]
Trusted Computer Solution Inc., http://www.tcs-sec.com/products/1products7.html
[84] CCEVS, http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#operatingsystem