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 Korea, the R & D of Trusted OS has been on since late 1990. Workers at KISA and ETRI have pioneered research in the area and, the first commercial version was announced in 2000. The R & D trend follows the worldwide trend: MAC and RBAC implementation, separation between enforcement mechanism and policy application, and module type implementation. This report summarizes Trusted OS developmental activities and currently active projects including those in Korea. In this report we will limit our investigation to the Trusted OS based on security kernel although there are many other approaches to OS security.

 

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 Korea, the R & D of Trusted OS has been practiced since late 1990s. Researchers at KISA and ETRI pioneered the initial surveys and have completed several projects. TSonNet [13] and Secuve [14] officially announced their first commercial version of Trusted OS in 2000. It is not dominating the research in system security but research work at universities has grown considerably as can be gauged by results being reported at domestic conferences in the area of operating systems security since 1990.

In this report we present research and developmental activities in Trusted Operating Systems including efforts in Korea. The rest of this report is organized as follows. In chapter 2, we briefly review access control and Trusted OS. Chapter 3 and Chapter 4 present research and developmental activities around the world in general and in Korea, in particular. We conclude this report in Chapter 5.

 

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 Clark and Willson policy, Separation of duty policy, and Chinese Wall policy. Clark and Wilson policy [45], concentrates on well-formed transactions to keep the integrity of sequence while transactions are performed. Separation of duty policy [45], focuses on the division of responsibilities. Chinese Wall policy [44], prevents conflict of interests.

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 United States has evaluated the systems since 1984 [1].

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 gFortress 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: Bell LaPadula (BLP) model is implemented for 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), USA. It is known as its successful adoption to Linux community in recent days. SELinux included the Flask architecture [65] to support several access control polices with the high degree of flexibility in Linux OS.

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 userfs 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 echanf 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 usersf execution of that file by specifying eallow bash_t prog_exec_t:process execute;f 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 USA, except OS vendors, ARGUS [82] and TCS [83] are well-known and active in development. We can see a list of commercial products evaluated by CC on NIST CCEVS homepage [84].

4. Trusted OS developments in Korea

 

In Korea, initial research on Trusted OS started in the middle of 1990fs[4]. At that time, publications were made on study of access control models [10] and survey on forerunning Trusted OS projects such as DTOS [11]. Korean commercial products have been available since 2000 [12] from TSonNet [13] and Secuve [14]. In these days more than 10 companies are involved in development pending and awaiting CC (Common Criteria) evaluation result from KISA [15]. In research field early surveys was conducted by researches of KISA and ETRI [16]. Especially ETRI has continued their research and have developed TCSEC B2 compatible Trusted OS based on FreeBSD systems. KISA is the authority of evaluation of Trusted OS as well as other commercial security products.

This chapter presents generally known Trusted OS developmental activities in Korea.

 

4.1 L4Linux-MLS and RedOwl SecuOS

 

Researchers of Hanseo University (Dr. T. K. Park) have developed L4Linux Trusted OS [22, 23] running on L4 microkernel. L4 microkernel includes 7 IPC system calls and guest operating systems executed on user mode. L4Linux-MLS adopted MAC as well as DAC for enforcing multilevel security (MLS). In the implementation of L4Linux-MLS, the approach of Flask is adopted so as to clearly separate policy enforcement and configuration by placing the security server [Figure 6].

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 subjectfs uid, objectfs 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 userfs 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 Korea. SecuveTOS can encode userfs privileges associated with RBAC roles to the X.509 certificate.

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 Korea (50% of market possession in 2003) and have made effort to grow their market places in eight foreign countries including Japan and China.

 

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. Meta policy based approach is taken to coordinate organizational policies of each domain (each autonomous 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]

Red Castle

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 Korea have given attention on development of Trusted OS since late of 1990 and now users and IT manager has mind for adoption of Trusted OS. Amongst four known projects, SecurOS, L4Linux-MLS (RedOwl), and Secuve TOS has its attention on implementation of usable enforcement architecture with MAC and RBAC. SeeCure OS has concentrated on design of enhanced model of access control in research area.

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, gThe 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] United States Government National Computer Security Council, gTrusted Computer System Evaluation Criteria", Department of Defense Standard(DOD 5200.28-STD), Library Number S225, 711, 1985.

[8] E. G. Amoroso, Fundamentals of Computer Security Technology, AT\&T Bell Laboratories, Prentice Hall PTR., 1994.

[9] M. D. Abrams, S. Jajodia, and H. J. Podell, gInformation 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, gOS Security Technology Tendency,h ؚی{論, Vol. 8, No. 2, pp. 64-84, 1998.

[12] T. K. Park, gTendency of Research and Development of Secure Linux,h ؚی{, 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, gAccess Control for Secure FreeBSD Operating System,h 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, gA study of the method of providing secure network channel among secure OSs,h 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, gAutomatic Encryption Method within Kernel Level using Various Access Control Policy in UNIX system,h ؚ|{ C, Vol. 10, No. 4, pp. 387-396, 2003.

[20] J. S. Yu, J. D. Lim, J H. Nah, S. W. Sohn, gThe Design and Implementation of Module supporting Trusted Channel in Secure Operating System Environment,h ؚی{論, Vol. 14, No. 3, pp. 3-13, 2004.

[21] David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn and Ramaswamy Chandramouli,  "Proposed NIST Standard for Role-Based Access Control Model," ACM Transactions on Information and Systems Security, Vol. 4, No. 3, pp. 224-274, Aug. 2001.

[22] C. W. Lee, H. H. Kim, T. K. Park, gImplementation of L4-MLS with Security Servers,h Proc. of Joint Workshop on Information Security and Cryptology 2000, Okinawa, Japan, Jan. 2000.

[23] Tae Kyou Park, Yeon Ho Im, gImplementation of Secure Linux OS based on Kernel,h ؚی{論, 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, Hanseo University, http://infosec.hanseo.ac.kr/

[26] Y. C. Park, gTOS 2.5.50 Proposal,h Secuve, 2004.

[27] K. Y. Hong et al., gIntelligent Multilevel Information Protection System based on Secure OS,h ؚ|{, 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, gExtended Role Based Access Control with Procedural Constraints for Trusted Operating Systems,h 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., gA Sense of Self for UNIX processesh, IEEE Symp. on Security and Privacy, 1996.

[35] W. Shin and H. K. Kim, gA Simple Implementation and Performance Evaluation of the Extended-Role Based Access Control,h 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. Bell and L. LaPadula, gSecure Computer Systems: Mathematical Foundations,h MITRE Tech Report 2547, Vol I, 1 March 1973.

[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] Ravi Sandhu, and P. Samarati, "Access Control : Principles and Practice," IEEE Communications, Vol. 32, No. 9, Sep. 1994.

[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," U.S. Air Force Electronic Systems Division Technical Report 76-372, 1977.

[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, gThe Rule Set Based Access Control (RSBAC) Framework for Linux,h

[64] L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, S. A. Haghighat, gPractical Domain and Type Enforcement for UNIX,h Proceedings of the 1995 IEEE Symposium on Security and Privacy, 1995.

[65] Peter Loscocco, and Stephen Smalley, gIntegrating 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, gTowards a formal model for security policies specification and validation in the selinux system,h 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, gImplementing SELinux as a Linux Security Module,h December 2001 (Revised in Feb. 2005).

[69] Massimo Bernashi, Emanyele Gabrielli, Luigi V. Mancini, gREMUS: A Security-Enhanced Operating System,h 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, gIncreasing Performance and Granularity in Role-Based Access Control Systems: A case study in GRSecurity,h http://www.grsecurity.net/papers.php

[72] Brad Spengler, gGRSECURITY ACL DOCUMENT V1.5,h http://www.grsecurity.net/papers.php

[73] PaX, http://pax.grsecurity.net/

[74] Xie Huagang, gLIDS Hacking HowTo,h v1.0, 29 March 2000.

[75] Yusuf Wilajati Purna, gTrusted Domain Enforcment (TDE): An Introduction,h Sep. 2004.

[76] MEDUSA DS9 Project, http://medusa.fornax.sk/

[77] Marek Zelem and Milan Pikula. ZP Security Framework. http://medusa.fornax.sk/English/medusa-paper.ps.

[78] Domain and Type Enforcement for LINUX, http://www.cs.wm.edu/~hallyn/dte/

[79] Serge E. Hallyn, Phil Kearns, gDomain and Type Enforcement for Linux,h In proc. of the 4th annual Atlanta Linux Showcase, Oct 2000.

[80] Lee Badger et al., gA Domain and Type Enforcement UNIX prototype,h In proc. of the fifth USENIX UNIX Security Symposium, 1995.

[81] Kenneth M. Walker et al., gConfining Root Programs with Domain and Type Enforcement (DTE),h 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

 



[1] Date: May 18, 2005

[2] http://seecure.dumpcode.net

[3] IBM, Sun Microsystems, HP, RedHat, SuSe, ARGUS, TCS are all registered trademark of each company.

[4] We limit our attention on the enhanced access control applied systems and only refer available online documents form KISS, KIPS, KIISC, and KISA for Korean domestic survey.

[5] It is rather hard to find relevant research papers concerning the SecuveTOS except some elementary survey papers or documents for market PR.