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)  and the Linux Security Module  (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 . 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).
All components with a question mark are open to design and development contribution.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide