Nimbus™
SELinuix and Nimbus

In the last ten years, Linus clustered supercomputing has developed from a curiosity to the dominant cwtype of supercomputer employed in HPC. New developments in commodity hardware continue to chip away at the last few percent of problems that still require 'big iron'.

The next generation bproc system has made great strides to improved management and single system image in a cluster system.

A notable exception to the progress has been in the area of of security features such as role based access control, system auditing, and mandatory access controls. Situations remain where but for the need for those features, computation would be done more cost effectively on a cluster.

Nimbus 4.0 bridges that gap by introducing support for the NSA's SELinux in a cluster environment. Like everything else in Nimbus, security policy is controlled by the master node. Linux Labs international has added and modified software to automatically mirror the master's policy onto compute nodes as they come up, and to migrate process security attributes wherever the process migrates or forks to. Because of this startup method, SELinux may be configured using only the standard toolset or (if preferred), editing the policy source by hand.

Because of the nature of the bproc single system image, and the SELinux modifications made in Nimbus, targeted security policies 'just work' when employed on a Nimbus cluster.

The security attribute migration occurs within the kernel's bproc module in order to minimize a user's opportunity to subvert the system from userspace.

Currently, the system defaults to targeted/enforcing. This may be configured (as in the general case) by configuring the master appropriately. At the present time, the strict policy is not supported due to difficult to avoid differences in required permissions for an application to run in a cluster, primarily in that a process started through the bpsh utility will require some TCP access in order to enable stdio redirection. While that does not intrinsically preclude use of a strict policy, it would require significant changes to the policies that would work in a single server environment. Given a sufficiently strong need, the cost/benefit of a Nimbus cluster over 'big iron' would likely justify this additional work.

Meanwhile work continues to extend the existing targeted policy to more finely compartmentalize the system daemons and more tightly wrap them in domains consist ant with least required permission. This work includes the 'standard' daemons, clustering specific daemons, and the general purpose daemons Nimbus adds to the base of Fedora core 4 and Debian Sarge.

Additional design work to securely allow stdio redirection without significant modifications to standard policies is currently under consideration.