NSAs Security-Enhanced Linux

Trojan

What:

This version of Linux has a strong, flexible mandatory access control architecture incorporated into the major subsystems of the kernel. The system provides a mechanism to enforce the separation of information based on confidentiality and integrity requirements. This allows threats of tampering and bypassing of application security mechanisms to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications.

Linux was chosen as the platform for this work because its growing success and open development environment provided an opportunity to demonstrate that this functionality can be successful in a mainstream operating system and, at the same time, contribute to the security of a widely used system. Additionally, the integration of these security research results into Linux may encourage additional operating system security research that may lead to additional improvement in system security.

i.e. basically kernel and filesystem level security mechanisms

Site: http://www.nsa.gov/selinux/
FAQ: http://www.nsa.gov/selinux/faq.html
Download: http://www.nsa.gov/selinux/src-disclaim.html

What does Security-enhanced Linux give me that standard Linux can't?

The Security-enhanced Linux kernel enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. When confined in this way, the ability of these user programs and system daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example) is reduced or eliminated. This confinement mechanism operates independently of the traditional Linux access control mechanisms.

It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries). The security of an unmodified Linux system depends on the correctness of the kernel, all the privileged applications, and each of their configurations. A problem in any one of these areas may allow the compromise of the entire system.

In contrast, the security of a modified system based on the Security-enhanced Linux kernel depends primarily on the correctness of the kernel and its security policy configuration. While problems with the correctness or configuration of applications may allow the limited compromise of individual user programs and system daemons, they do not pose a threat to the security of other user programs and system daemons or to the security of the system as a whole.

7.How compatible is Security-enhanced Linux with unmodified Linux?
The Security-Enhanced Linux provides binary compatibility with existing Linux applications. It provides source compatibility with existing Linux kernel modules. These two categories of compatibility are discussed in detail below:
A.Application compatibility
We provide binary compatibility with existing applications. We have extended kernel data structures to include new security attributes, and we have added new system calls for security-aware applications. However, we have not changed any data structures visible to applications and we have not changed the interface of any existing system call, so existing applications can run unchanged if the security policy authorizes their operation. For security attributes on files in ext2 file systems, we store an index in an unused field in the on-disk inode that refers to security attributes stored in label mapping files in each file system. Existing ext2 file systems are automatically converted when mounted, but this conversion does not prevent the file system from still being used on a vanilla Linux system. However, if a vanilla Linux kernel is subsequently used with a converted file system, and files are created by it, these files will need to be relabeled when the file system is used with Security-enhanced Linux again. The easiest way to ensure that files are labeled properly is to do a 'make clean; make relabel' in the policy directory.
B.Kernel module compatibility
We provide source compatibility with existing kernel modules. We have added new kernel functions that are exported for kernel modules, but we have not changed existing exported function interfaces. However, the changes to kernel data structures require recompilation of kernel modules in order for them to be used with our kernel.
The Security-enhanced Linux also provides a development mode as a kernel configuration option (CONFIG_FLASK_DEVELOP) that audits but does not enforce the mandatory access controls. We are using this mode while developing the mandatory access controls and security policies in order to determine the permissions required for the system to operate. When compiled with this option, the kernel is initially permissive, and it can be toggled between being permissive and enforcing permissions at any time. New users of the Security-enhanced Linux will likely want to use this mode initially because their systems may require some permissions that are not included in the example security policy configuration, especially since the example configuration is not yet complete. For "operational" use, the kernel should be built without this option.

The Security-enhanced Linux should not introduce any interoperability problems with ordinary Linux systems as long as all desired operations are authorized by the security policy configuration.

Interesting. Comments?

Al.

ecksor

Nothing new in terms of the technology there, but I think (open to correction here) that it's the first time the source to such a system has been released. The NSA have been pushing for better security mechanisms and more assurance in commercial software (operating systems in particular) and so decided to put some work out there to show people how it's done. If third party software is brought up to scratch, then the NSA will outsource some of it's less critical stuff while still being sole providers for the most important products.

Not really sure if it has had the desired effect, must dig around ...