GridBox: Securing Hosts from Malicious and Greedy ...

GridBox: Securing Hosts from Malicious and Greedy Applications Evgueni Dodonov

Joelle Quaini Sousa

Hélio Crestana Guardia

DC-UFSCar Washington Luis, Km 235 Sao Carlos (SP), Brazil

DC-UFSCar Washington Luis, Km 235 Sao Carlos (SP), Brazil

DC-UFSCar Washington Luis, Km 235 Sao Carlos (SP), Brazil

[email protected]

[email protected]

[email protected]

ABSTRACT Security is an important concern in providing the infrastructure for the implementation of general purpose computational grids. However, most grid implementations focus their security concerns in correctly authenticating users and hosts and in the communications among them. In most cases, application security is left to the underlying operating system. This can be a problem when a “malicious” application is executed. In this work, we introduce the GridBox architecture, that aims to provide additional security for GRID applications, using Access Control Lists and sandbox functionality for GRID tasks.

1.

INTRODUCTION

The infrastructure of a Computational Grid should supply basic services for control, communications and secure sharing among the Grid’s resources. Because this computational structure is highly distributed, shared, and sometimes interlinked through a public data communications channel, security is also a crucial issue. Grid design involves the use of distributed computational resources for the solution of specific problems. The development of an infrastructure for the implementation of general purpose Grids is also considered in projects such as [18], [19]. In order to provide security for the GRID communication, usually some sort of connection security, such as SSL, GSS-API and X.509 certificates is used. However, most of the existing GRID architectures do not provide additional security for the GRID applications, making it possible to harm the members of a GRID network with malicious code. In this paper, we present an architecture for computational GRID security, created to provide additional security for GRID applications. The architecture uses the concepts of sandbox and Access Control Lists in order to limit the functionality of grid applications, allowing a fine tuning of most system accesses by every application. The paper is structured as follows: A series of different security approaches is shown in the section 2, together with a discussion about existent grid architectures and

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 2nd Workshop on Middleware for Grid Computing Toronto, Canada Copyright 2004 ACM 1-58113-950-0 ...$5.00.

their security models. The proposed GRIDBOX architecture is described in the section 3. Finally, the sections 4 and 5 present the results obtained and conclude this work.

2.

GRID SECURITY

The traditional UNIX and the most widely used security model (the so-called DAC model), composed of a limited set of permissions (namely, user-group-other permissions) does not provide the flexibility necessary for modern systems. Currently, in the server or distributed environment the security of the system processes became the crucial point of overall system security. Traditional UNIX security model does not provide additional security for different processes, allowing a single process error to affect other processes, especially when run as a privileged user. Secure programs have to minimize privileges so that any malicious programs are less likely to be become security vulnerabilities. Even programs formally proved correct using sophisticated mathematical techniques are prone to have malfunctions. Basically, the three approaches to security enforcement are: • Process separation – this approach consist of separation of processes in the system, usually by limiting the file system access (chroot, sandbox and jail approaches). This way, each process can only access its files, preventing it from affecting other applications. • Security enforcement – this approach attempts to tighten the security by defining all possible process functions and allowing limited access to the system. This approach is used in SELinux technology. Usually, this technology uses the Access Control Lists in order to limit the system access for each application. • System restriction – UMLinux [4] and VServer [20] introduced a new security model, which consist of the creation of different virtual servers in the same operating system. This way, each process has the usual access to its system but runs independently from each other. ACL, the Access Control List technology represents an extension of the basic permissions, consisting of user, group and other parts. Usually unix machines can only specify permission for each file based on its owner and group it belongs to. It becomes quite a limitation when different privileges are necessary. The ACL solution associates a list of permissions for an object. This way, it is possible to define precisely what users may access a file. This solution is being used in the NTFS file system [13] and in the Linux kernel, using Extended Attributes technology [9].

SELinux, the Security-enhanced Linux [16], is an operating system based on Linux which includes Mandatory Access Control. It works with the LSM (Linux Security Modules) framework, a feature that was added to the kernel with the 2.6 release. Linux 2.4 kernels may be patched to support LSM and SELinux. SELinux was developed by the NSA in cooperation with various contractors such as MITRE and NAI Labs. It was derived from the Flask [17] security architecture which was a part of the Flux research operating system. Instead of using DAC (Discretionary Access Controls) mechanisms, used in most UNIX systems, which determine what a program can do based only on the identity of the user running the program and ownership of objects such as files, sockets and so on, SELinux is based on MAC (Mandatory Access Control) mechanisms. It was considered by their pioneer developers, the NSA agency[12], that DAC has not provided enough defense against vulnerable or malicious programs. NSA’s research arm then worked to try to make MAC more flexible and easier to include in operating systems. They developed prototypes of their ideas using the Mach operating system, and later sponsored work extending the “Fluke” [7] research operating system. SELinux’s new features are designed to enforce the separation of information based on confidentiality and integrity requirements. They are designed for preventing processes from reading data and programs, tampering with data and programs, bypassing application security mechanisms, executing untrustworthy programs, or interfering with other processes in violation of the system security policy. They also help to confine the potential damage that can be caused by malicious or flawed programs. They should also be useful for enabling a single system to be used by users with differing security authorizations to access multiple kinds of information with differing security requirements without compromising those security requirements. Thus, the SELinux technology allows a complete control over each and every system component. However, the main drawbacks of the SELinux technology are the need to define precisely all rules for its policy and a complex policy design. UMLinux, the User Mode Linux [4] solution aims to provide a complete linux-inside-linux solution for any kind of application. User-Mode Linux creates a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file in the physical machine. It is possible to assign to the virtual machine only the hardware access it needs. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software [5]. This approach provides a good security at the cost of running an operating system inside aother operating system, thus decreasing the performance of all operations. Sandbox [8] approach is a light-weighted model of process separation. This approach is widely used in JAVA Architecture, allowing only limited access for the applications inside the sandbox. Basically, the sandbox approach provides a reserved area for each application, inside which the application can perform its operations normally, restricting the access to the outside. This approach combines good security with a low overhead, thus offering good performance. However, in most cases this approach is not implemented on the system level. The chroot [11] command and system call can be considered a reduced sandbox, as it only restricts the filesystem operations of a process. Furthermore, it is possible for the applications run as the system administrator to escape the chrooted environment and gain full file system access [15].

Jail [10] approach is a FreeBSD-only implementation of a combination of chroot with sandbox approach. Basically, each jailed application has its own space together with an IP address. In this way, the security of sandbox approach is implemented directly into operating system, offering a good performance combined with tight security. As can be seen, different approaches can be used in order to enforce the basic security provided by the operating system. Some of these approaches are restricted to the operating system used (such as jail, which can only be used on FreeBSD systems or UMLinux, only available on Linux machines), which is not the case for a GRID network. In a grid network, different operating systems and machine architectures may be present, thus limiting the availability of some of the present security technologies. The most widely known grid architectures are the Globus Toolkit [18], Apple XGrid [2], OurGrid [1] and the ProGrid technologies [3]. Globus consists of a research and development project focused on enabling the grid application concepts to be applied to scientific and business computing. It deals with the meta-computing systems limitations due to its heterogeneous and dynamic nature that restricts the applicability of current parallel computing tools and techniques. While meta-computing can build on distributed and parallel software technologies, it also requires significant advances in mechanisms, techniques, and tools. The Globus project is intended to accelerate these advances. The most important core middleware components in Globus are GRAM (Globus Resource Allocation and process Manager), Nexus (Network heterogeneous communication infrastructure), MDS (MetaComputing Directory Information Services), GSI (Grid Security Infrastructure), GASS (Global Access to Secondary Storage) and GEM (Global Executable Manager) and HBM (Heartbeat Monitor) [18]. The Globus Security Infrastructure (GSI) enables a decentralized security management together with a single sign-on for users of the grid. It is based on X.509 certificates, and the Secure Sockets Layer (SSL) communication protocol. GSI also supports proxy credentials, inter-operability with local security mechanisms, local control over access, and delegation. A wide range of GSI-based applications have been developed, ranging from ssh and ftp to MPI, Condor, the SDSC Storage Resource Broker and so on. Apple Xgrid technology allows to transform a group of Macs into a supercomputer, allowing them to share resources in order to resolve problems that require more computational power. The Xgrid aims to provide an easy to deploy and use GRID solution, automatically discovering available nodes and distributing tasks among them. Besides the ad hoc approach, the Xgrid technology can be used to create a dedicated GRID architecture. Security within the Xgrid architecture is enforced by the default UNIX permission model, where the daemons are running under an unprivileged user which has limited access to the system. Also, a password is requested by default for connections, further increasing the security. Currently, only the password negotiation is encrypted, while the transmitted data passes unencrypted. Another approach for the grid applications is introduced in the OurGrid [1] project. The project uses the bag-of-tasks concept, allowing parallel applications to run on a grid environment. The OurGrid project provides support for grid economy, disallowing the abuse of grid resources by greedy applications together with a security mechanisms for authentication, authorization and similar. However, no additional application security is provided, thus allowing a malicious application to compromise the

grid nodes. The ProGrid approach [3] introduces the concept of Grid Proxies, which stand between different grid networks, reducing the number of needed connections between hosts. The proxy servers aim to increase the security of inter-grid communication providing support for host and user authentication and security for messages exchanged between different grid networks. The main objective of the ProGrid project is to provide transparent proxies for different grid subnetworks, which act as gateways between these networks. All communications between different networks require user and application authentication, increasing the overall grid security. Thus, the ProGrid architecture aims to enhance existing grid networks with additional security for inter-grid connections and to reduce the number of host-to-host connections between different grid subnetworks. However, as the ProGrid approach interacts between different grid subnetworks, the security of individual hosts is not enforced. Further, the ProGrid aims to provide secure connections between hosts and networks but no additional security is provided, allowing a malicious application to compromise the grid network. Currently, none of these architectures focus on application security, leaving most security aspects to the operating system. In the time of the first grid projects, such security aspects had no practical aspects, as each grid project had complete control over the data transmitted. This way, a malformed data could hardly compromise the grid network. The security, however, becomes quite a concern in modern general purpose applications, where a malicious code can damage the grid.

3.

system access must occur as usual, and the security subsystem must take care of each possible violation. • Isolation – each application must run independently from other applications on the same machine. In order to comply to all these requirements, the so-called process limitation was implemented in the GridBox architecture: The GridBox architecture intercepts the processes system calls and checks them against the pre-defined access control list. If the request is explicitly defined in the ACL, the action is taken immediately, either effectively executing the request or returning an error code. The ACL is created just before the process execution, with base on: • Node profile – each grid node has its profile of execution, specifying basically which actions it is allowed to perform. A sample profile is present in table 1. # Node profile # Allow the processes to access # the file system subsystem FS allow # Allow the processes to access # the network subsystem NET allow # Disallow the processes from # executing new applications subsystem EXEC deny subsystem EXEC allow_override

GRIDBOX ARCHITECTURE

In this paper, we introduce the GRIDBOX architecture for grid security. As we demonstrated above, most GRID architectures provide security services for communications and authentication, leaving the security of application to the underlying system. This can be a problem, specially when we have a grid with a thousands machines – a simple malformed application can disable the grid completely. Further, a security architecture becomes a need for ordinary users who offer their machines for a GRID network. The security is one of the most important aspects in such cases, as a malformed application could damage the user machine. In a grid environment, the security of the grid nodes is extremely important for grid functionality, and malicious applications must not be allowed to cause system damage. In order to provide additional security services for grid applications, the GridBox architecture was conceived. The main objectives of this architecture are: • System security – the system must be protected from possible hostile acts performed by an application. • Interoperability – concurrent applications must not interfere with each other. E.g., application A must not modify application B’s files, and so on.

Table 1: Sample node profile A Node Profile defines only the default permissions for each subsystem. It is possible to detail the actions on a per process basis. • Application policy – in order to further define the application behavior, each application may have an application policy file, which describes each action that the application must be allowed to perform. A sample application policy is shown in table 2. As can be seen, the policy determines what actions should be allowed or denied for the application. The node profile has precedence over the application policy, preventing the applications from overriding node security configuration. In the examples shown in Tables 1 and 2, even when the application policy allows the execution of /bin/cat application, the node profile disallows any program execution, unless the allow_override condition is explicitly set. In this case, the application will succeed in /bin/cat execution.

• Tunable settings – each application can have different requirements for system functions. For example, application A must have access to the network subsystem but not to the filesystem; and application B only uses the filesystem. It should be possible to fine-tune these parameters for each application with no additional user actions.

It is possible to include more specific policy settings in the node profile, making these values valid for all applications that will be executed on the system. For example, if the rule

• Transparency – the application does not have to know about the underlying security subsystem. For the application, each

is defined in the node profile, no application will be able to execute the /bin/rm program.

rule system deny /usr/bin/rm

# Application profile # job1 # File system accesses # Allow read-write access # to "input.txt" and "output.txt" # files rule fopen allow input.txt rule fopen allow output.txt

# Node profile # Limit the CPU use to 5 minutes limit CPU_TIME 600 # Limit maximum file size limit FILE_SIZE 1000000 # Limit maximum process stack limit STACK 20000

# Allow read-only access to # /etc/hosts file rule fopen readonly /etc/hosts # Disable all other accesses rule fopen deny * # Network acceses # Establishing connections # Allow connections to trusted machines rule connect allow 200.18.98.120:80 rule connect allow 200.18.98.132:80 rule connect allow 200.18.99.221:80

Table 3: Sample node limits

This approach has some benefits together with several drawbacks: • Among the benefits provided by the approach we can mention the complete transparency of the GridBox integration to existing applications. No need for recompilation nor modification to existing applications is required to support the provided architecture. In order to prevent the application from re-defining system calls by loading the functions directly from a shared library, the function loading call is intercepted by the GridBox library, disallowing the application from using direct system calls.

# Allow SSH connection rule connect allow 200.18.98.22:22 # Disallow any other connection rule connect deny *:* # Serving connections # Allow to bind to port 8000 of # interface 200.18.98.120 rule bind allow 200.18.98.120:8000 # Disallow any other port binding rule bind deny *

• However, the drawback of the shared library is the inability to provide security for statically-linked applications, thus limiting the provided architecture to dynamically linked applications only. In order to use the GridBox architecture with static applications, such applications must be recompiled with the GridBox library. By default, the GridBox does not allow the execution of staticallylinked applications which were not recompiled with GridBox security enabled.

# Program execution # Allow execution of /bin/cat rule system allow /bin/cat # Disallow any other program execution rule system deny *

Table 2: Sample application policy

• Environment restriction – in order to protect each application’s space from other intervention, each application is executed in separated filesystem space, protected by the chroot mechanism. Also, the node profile can define the default system parameters for the application, such as the maximum CPU and memory usage, maximum number of open files, and so on, as shown in Table 3. All these limits are independent from the application being executed, and are being enforced transparently by the GridBox.

3.1

Implementation

In order to transparently enable the GridBox interaction with existing application the architecture was implemented as a shared library. The library is preloaded into memory before real application execution, overriding the system provided functions with new ones. The implemented GridBox library can be used on any unix-like operating system which supports shared library technology.

3.2

Application Deployment and Execution

Considering the bag of tasks model of grid implementation, the security model proposed can be achieved as follows: • A user adds a host to the grid specifying its basic resctrictions when accepting applications from remote hosts. A very restrictive profile can be used as default. Otherwise, one can determine which directories and files can be used, as well as CPU limitations, and communication (sockets) restrictions. • A special local user account is created at each host for use with remote applications • Grid applications are deployed to the specified (or default) hosts on which they will be executed • The new shared library is preloaded into the memory • The application is initiated being limited at startup by the CPU restrictions imposed at each host. During run time the code is also checked against the local access restrictions In order to enable the GridBox for an application, it is necessary to: • Preload the shared library into memory before the application execution. This action is performed using the operating system facilities.

• Define the ACL for the application and the current host. In the actual GridBox implementation the ACL file location is defined by the environment variable GRIDBOX_CONFIG_FILE. On GridBox library load into memory, it reads the configuration file and processes the ACLs defined. After the library is loaded into memory and the ACL is fully processed, the application is executed. All interceptable system calls now are being intercepted by the GridBox and verified before their real execution.

4.

CASE STUDY

In order to validade the proposed architecture, we used two applications: one simple C application, used in order to verify the ability to intercept and process system calls; and SETI@HOME [14] client application for Linux environment, a first-generation widely used grid application.

4.1

System call interception

For our case study we used the so-called bag-of-tasks approach. This approach consists in executing previously deployed applications on the host machines. The deployment of the application was not the focus of this work, thus the tested applications were deployed using the SCP command. However, it is possible to deploy the application using any other method (such as P2FS [6] or GridFtp [18] protocol). In order to run the deployed applications, the SSH protocol was originally employed. In order to support the GridBox security architecture, the host machine’s setup was modified to run the applications inside the sandbox. This way, the original task invocation consisted of a single SSH call: ssh host /usr/local/grid/application This call was modified to include support for the GridBox: ssh host /usr/local/grid/sandbox.sh \ /usr/local/grid/application The /usr/local/grid/sandbox.sh script was created to preload the sandbox environment and configure the necessary ACLs automatically. No changes to the application were necessary. During application execution, the GridBox outputs the value of each system call and associated action. For example, the following application was created to test the GridBox security: #include ... int main(int argc, char **argv) { char files[3][20] = {"input", "output", "/etc/passwd"}; char addresses[3][20] = {"200.18.98.120", "200.18.98.120", "127.0.0.1"}; int ports[3] = {80, 22, 22}; int nices[3] = {10, 0, -10}; char commands[3][20] = {"/bin/ls", "/bin/rm", "/usr/bin/who"}; int sock, i; FILE *file; for (i=0; i < 3; i++) { file = fopen(files[i], "r"); if (file != NULL) fclose(file);

sock = client_tcp(addresses[i], ports[i]); if (sock > 0) close(sock); system(commands[i]); nice(nices[i]); } exit(0); } int client_tcp (char *address, int port) { ... }

The ACL used with the application is: rule connect allow 200.18.98.120:80 rule connect allow 200.18.98.120:22 rule connect deny *:* rule fopen readonly inputtxt rule fopen allow output.txt rule fopen deny * rule system allow /bin/ls rule system deny * rule nice allow 10 rule nice deny *

Executing the application inside the GridBox environment, the following results were obtained: GRIDBOX: GRIDBOX: GRIDBOX: acl.c acl.h ... run.sh GRIDBOX: GRIDBOX: GRIDBOX: GRIDBOX: GRIDBOX: GRIDBOX: GRIDBOX: GRIDBOX: GRIDBOX:

fopen (input): ALLOWED connect (200.18.98.120:80): ALLOWED system (/bin/ls): ALLOWED

nice(10): ALLOWED fopen (output): ALLOWED connect (200.18.98.120:22): ALLOWED system (/bin/rm): DENIED nice(0): DENIED fopen (/etc/passwd): DENIED connect (127.0.0.1:22): DENIED system (/usr/bin/who): DENIED nice(-10): DENIED

In this sample application, only four system calls were intercepted (fopen(), connect(), nice() and system()), for the sake of clarity. The intercepted commands illustrated the file system access (fopen), command execution (system), network connections (connect) and process priority changes (nice). As can be seen, for each intercepted system call GridBox showed the function executed, their parameters and the action taken by the security system. In a real world application, the number of intercepted system calls may vary significantly. This application was executed in ProGrid environment, with no additional modifications in the existing grid architecture.

4.2

Seti @ Home client

As an example of a real grid application, the Seti@Home client application was used together with the GridBox architecture. The application was first executed with no enforced parameters, in order to determine files and internet addresses used by the application. After determining these parameters, an Access Control List was created, restricting the application functionality:

rule rule rule rule rule rule rule rule rule

fopen fopen fopen fopen fopen fopen fopen fopen fopen

allow allow allow allow allow allow allow allow allow

pid.sah user_info.sah version.sah result.sah work_unit.sah key.sah result_header.sah outfile.sah state.sah

rule connect allow 127.0.0.1:80

The seti@home application was executed using -proxy in order to pass all the Internet connection through a local proxy server. The results of the application execution can be seen of figure 4 (most of the execution messages were removed for the sake of clarity). # /usr/local/grid/sandbox.sh setiathome -proxy 127.0.0.1:80 GRIDBOX: fopen (setiathome.config): ALLOWED GRIDBOX: open (lock.sah): ALLOWED ... SETI@home client. Platform: i686-pc-linux-gnu Version: 3.08 ... Scanning result header file. GRIDBOX: fopen (outfile.sah): ALLOWED GRIDBOX: fopen (key.sah): ALLOWED Beginning analysis... ...

Table 4: SETI@HOME inside GridBox execution Continuing the GridBox validation, a new application was created and executed in place of the seti@home client. The new application tried to read /etc/passwd file and to execute rm command. The result of the application execution can be seen on figure 5. # /usr/local/grid/sandbox.sh setiathome -proxy 127.0.0.1:80 GRIDBOX: fopen (/etc/passwd): DENIED GRIDBOX: system (/bin/rm): DENIED ...

Table 5: Malicious application inside GridBox execution

5.

CONCLUSION AND FUTURE WORK

In this paper, we presented an architecture for GRID security, composed of sandbox controlled by a set of access control lists for grid applications. This approach allows the security of grid applications to be tightened, restricting their access to the system. Thus, the possibility of a malicious code execution is reduced significantly, disallowing grid application from damaging the host system and interfering with other applications on the same host. Using the proposed architecture, different aspects of every grid application can be controlled, allowing and disallowing system calls based on the defined ACLs. Considering the performance interference introduced in an application, it will depend on the number of system calls realized. It should not be relevant on CPU bound applications (IO-Bound applications influence is being studied). On the other hand, the proposed model increases the user confidence when accepting applications to be executed on a general purpose grid implementation.

For future work, the project of an analyzer tool for automatic ACL creation for grid applications is being conducted. Beside that, an architecture for the ProGrid environment, featuring automatic web-based grid application management is being developed. Our goal for that architecture is to provide automatic ACL generation for all grid applications, and to deploy the required GridBox library with the correspondent ACL to the grid nodes transparently.

6.

REFERENCES

[1] N. Andrade, W. Cirne, F. Brasileiro, and P. Roisenberg. OurGrid: An approach to easily assemble grids with equitable resource sharing. In Proceedings of the 9th Workshop on Job Scheduling Strategies for Parallel Processing, June 2003. [2] Apple Computer, Inc. X-grid project. http://www.apple.com/acg/xgrid/. [3] P. Costa, S. D. Zorzo, and H. C. Guardia. Progrid: A proxy-based architecture for grid operation and management. In Proceedings of SBAC-PAD 2003, 2003. [4] J. Dike. A user-mode port of the linux kernel, 2001. [5] J. Dike. The user-mode linux kernel home page. http://user-mode-linux.sourceforge.net/, 2004. [6] E. Dodonov and H. C. Guardia. P2fs: Peer-to-peer grid filesystem. http://www.gsdr.dc.ufscar.br/p2fs/. [7] B. Ford, M. Hibler, J. Lepreau, R. McGrath, and P. Tullmann. Interface and execution models in the fluke kernel. In Operating Systems Design and Implementation, pages 101–115, 1999. [8] L. Gong, M. Mueller, H. Prafullchandra, and R. Schemers. Going beyond the sandbox: An overview of the new security architecture in the Java Development Kit 1.2. In USENIX Symposium on Internet Technologies and Systems, pages 103–112, Monterey, CA, 1997. [9] A. Grünbacher. Linux extended attributes and acls. http://acl.bestbits.at/. [10] P. Kamp and R. N. M. Watson. Jails: Confining the omnipotent root. http://docs.freebsd.org/44doc/papers/jail/jail.html, 2000. [11] R. McGrath and Free Software Foundation. Chroot – run command or interactive shell with special root directory. The Linux Manual Pages. [12] NSA.GOV. Security-enhanced linux. http://www.nsa.gov/selinux/. [13] NTFS.COM. Ntfs - new technology file system designed for windows nt, 2000, xp. http://www.ntfs.com/, 2004. [14] SETI@HOME. Seti@home project. http://setiathome.ssl.berkeley.edu/. [15] Simes. Breaking out of a chroot() padded cell. http://www.bpfh.net/simes/computing/chroot-break.html. [16] S. Smalley, C. Vance, and W. Salamon. Implementing SELinux as a Linux security module. NAI Labs Report #01-043, NAI Labs, Dec 2001. Revised May 2002. [17] R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau. The Flask security architecture: System support for diverse security policies. In Proc. of the 8th Usenix Security Symposium, pages 123–139, 1999. [18] The Globus Project. http://www.globus.org. [19] The Legion Project. http://legion.virginia.edu. [20] The Linux VServer Project. Linux vserver project. http://www.linux-vserver.org/.