DSI: A New Architecture for Secure Carrier-Class Linux Clusters

The auditing service provides the system with auditing capabilities. On the security manager side, the service is responsible for gathering traces, analyzing the traces, detecting the possible attack patterns, triggering the alarms and propagating them through SCC. It must be possible to modify the level of logging generated through security management systems. This service is responsible for functionality related to the lawful intercept.

This service has increased functionality on the security server. It also monitors the internal network for the cluster and the distributed logs in order to detect attacks. This service on the security server is related to external IDS through SCC. The auditing service is connected to external loggers when needed. The connection between the auditing service and external loggers is not through SCC for performance reasons.

The work described here distinguishes itself by being focused on the design of a security infrastructure targeted for clustered servers, as compared to previous work that focused on single computers or general-purpose clusters. In addition, DSI takes into account all of the issues related to security management starting at the design level.

Some of the related work includes CorbaSec, the CORBA security service that handles the security issues regarding access control and authentication for interactions between different objects. CorbaSec does not take into account all aspects of security for example detection and reaction mechanisms like DSI. On the other hand, Security Enhanced (SE) Linux from the National Security Agency (NSA) [3] and the Linux Security Module [4] (LSM) effort run on a single computer; they do not extend to a cluster.

Finally, Grid Security Infrastructure (GSI) was subsequently developed, based on existing standards, to address the security requirements that arise in Grid environments [5]. The DSI approach is more fine-grained and is based on modifying the OS to enhance security mechanisms (as explained previously). The approach of DSI is possible because the software and hardware configuration in the cluster is under tight control. In practice, DSI supports a coherent vision of security throughout the whole cluster as GSI supports secure interoperable mechanisms between different trust domains for multiple users.

So far, a secure boot mechanism for diskless Linux servers was implemented. Using secure boot with digital signatures, a distributed trusted computing base (DTCB) will be available as of the boot of the cluster nodes. The kernel at secure boot is small enough to be thoroughly tested for vulnerabilities. Furthermore, the use of digital signatures for binaries and a local certification authority will prevent malicious modifications to the DTCB.

We also implemented a security module based on Linux Security Module (LSM) that enforces the security policy as part of the DSI access control service. This module is integrated with SCC to implement distributed access control mechanisms. DSI currently supports pre-emptive and dynamic security policy at the process level throughout the whole cluster. Currently we are implementing the distributed security policy. To ease administration and maintenance of this policy, we are completing a study to devise methods to reuse information already contained in package management systems (such as RPM for Linux) in order to generate part of the security policy or to push such information to the package (if that is where it would be best specified). This effort also aims to use the policy to provide clearly different privileges during software, installation, configuration, activation, and execution. Specification of the exact language used to express the policy and of the compilation and loading mechanisms remains to be completed.

We have partly implemented a secure communication channel based on OmniORB, an open-source implementation of CORBA. SCC logics are implemented on top of a portability layer. This makes the implementation independent of any communication middleware used. The choice of CORBA as communication middleware for SCC was motivated by many factors, such as the support for distributed real-time and embedded systems and interoperability.

The Open Systems Lab at Ericsson Research started the DSI project to provide an architecture that supports different security mechanisms for telecom applications running on carrier class Linux clusters. The development direction is to make the DSI framework open source and to get people from different organizations and as well as open source initiatives involved in the design and development of the various components.

Figure 5 presents the various components of DSI. Currently at Ericsson Research we are working towards implementing the core DSI which includes the following components: Secure Communication Channel, Security Server, Security Manager, Access Control Service (including LSM module), Security Policy Generation, Security Session Manager and a Distributed Tracing of Event (as part of the Auditing Service).

Figure 5. DSI Components

All components with a question mark are open to design and development contribution.