DSI: A New Architecture for Secure Carrier-Class Linux Clusters
DSI introduces original contributions in the area of security on clustered systems. However, some parts, such as Access Control Service and the use of security contexts and identifiers, owe much to existing propositions, like Security Enhanced (SE) Linux.
DSI has two types of components: management and security services.
The DSI management components define a thin layer that includes a security server, security managers and a security communication channel (Figure 1). The service layer is a flexible layer that can be modified or updated through adding, replacing or removing services according to the needs of the cluster.
The security server is the central point of management in DSI, the entry point for secure operation and management and intrusion detection systems from outside the cluster. It is responsible for the distributed security policy. It also defines the dynamic security environment of the whole cluster by broadcasting changes in the distributed policy to all security managers.
Security managers enforce security at each node of the cluster. They are responsible for locally enforcing changes in the security environment. Security managers exchange security information only with the security server.
The secure communication channel provides encrypted and authenticated communications between the security server and the security managers. All communications between the security server and the outside of the cluster take place through the secure communication channel. Two nodes (to avoid a single point of failure) host the security server, and different security service providers, such as the certification authority, are hardened to maximize security. All connections from and to these nodes are encrypted and authenticated.
The security mechanisms are based on widely known, proved and tested algorithms. For the security mechanisms to be effective, users must not be able to bypass them. Hence, the best place to enforce security is at the kernel level; all security decisions, when necessary, are implemented at kernel level, the same as for the main security manager component, which has stubs into the kernel. In the Linux operating system, these stubs are implemented through load modules.
The DSI architecture at each node is based on a set of loosely coupled services (Figure 2).
The security manager controls different security services on the node. This service-based architecture has the following advantages:
The service implementation is separated from the rest of the system. By keeping the same API, the service implementation can be changed without affecting the application. However, an API for accessing security services is provided at user level for applications with special security needs (Figure 3).
It runs only predefined services according to the needs, performance issues or security environment. In addition, services can be replaced during runtime without major drawbacks on the running application. This enables the architecture to be modified and to resist changes throughout the system's lifetime.
It is possible to add, remove or update different services without administrative intervention. This reduces configuration errors due to the numerous security patches that need to be applied manually.
The security manager discovers the different services. Each service, upon its creation, sends a presence announcement to the local security manager, which registers these services and provides their access mechanisms to the internal modules.
There are two types of services: security services (access control, authentication, integration, auditing) and security service providers, which run at the user level and provide services to security managers.
The security server is the reference for all security managers and has the authority to declare a node to be compromised. It subscribes to all updates to keep its cache of different security contexts up to date, which makes it the ideal candidate for running Intrusion Detection Systems (IDSs). It has a local certification authority, as it certifies public keys for secondary certification authorities run by the security managers.
The primary tasks for security server include auditing, triggering alarms and warnings inside and outside the cluster, managing the distributed security policy and propagating security operation and management information.
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- SUSE – “Will not diverge from its Open Source roots!”
- Dealing with Boundary Issues
- Vagrant Simplified
- Libreboot on an X60, Part I: the Setup
- System Status as SMS Text Messages
- October 2015 Issue of Linux Journal: Raspberry Pi
- Bluetooth Hacks
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- New Products
- October 2015 Video Preview