Creating a usable secure operating system remains a critical research problem. Linux has several security developments included in its open source operating system. Among these are SELinux, chroot jail, and iptables to name a few.
SELinux is Security Enhanced Linux. The National Information Assurance Research Laboratory of the National Security Agency was in charge of carrying out the research and advanced development of technologies needed to enable the NSA to provide the solutions, products, and services to achieve Information Assurance for information infrastructures essential to the security of the U.S. National Security. The Security-enhanced Linux prototype was developed by the NSA along with research partners from NAI Labs, Secure Computing Corporation (SCC), and the MITRE Corporation. Many other contributions have followed since the initial release.(NSA-National Security Agency, 2009)
Researchers in the National Information Assurance Research Laboratory of NSA worked with Secure Computing Corporation (SCC) to develop a strong, flexible mandatory access control architecture based on a mechanism first developed for the LOCK system called Type Enforcement. The NSA and SCC then worked with the University of Utah’s Flux research group to transfer the architecture to the Fluke research operating system. The architecture was enhanced, when it was transferred, to provide better support for dynamic security policies. This enhanced architecture was named Flask. SELinux implements the Flask security architecture which uses flexible mandatory access control. Flask was created to demonstrate the value of flexible mandatory access controls and how such controls could be added to an operating system. The Flask architecture has been subsequently mainstreamed into Linux® and ported to several other systems, including the Solaris™ operating system, the FreeBSD® operating system, and the Darwin kernel, generating a wide range of related work. The Flask architecture provides general support for the enforcement of many kinds of mandatory access control policies, including those based on the concepts of Type Enforcement®, Role-based Access Control, and Multi-level Security. (NSA-National Security Agency, 2009)
The core SELinux user code consists of libsepol a library for binary policy manipulation, checkpolicy a policy compiler, libselinux a library for security-aware applications, libsemanage a library for policy management tools, and policycoreutils that contains several policy-related utilities. (NSA-National Security Agency, 2009)
Privacy and integrity requirements are the new features that enforce the separation of information in SELinux. They prevent processes from reading data and programs, tampering with data and programs, bypassing application security, executing untrusted programs, or hindering the use of other processes in violation of the system security policy. They also help to restrict the potential damage that can be caused by malicious or flawed programs. They should also be useful for enabling a single system to be used by users with different security authorizations to access several kinds of information with different security requirements without compromising their security requirements. (NSA-National Security Agency, 2009)
SELinux is a fairly new security protocol. It is very proud of its security enhancements. It can also be very complicated and cause problems with permissions and denials if the many policies are not set correctly. You can make SELinux do what you need it to do if you learn the basic concepts and become familiar with the list of terms and study some representative policy files. Any security protocol can be bypassed, but SELinux does a good job of limiting the amount of damage that an intruder can do to the operating system.
On Unix-like operating systems, such as Linux, a chroot jail is the common expression used to describe a section of a filesystem that is sectioned off for a particular user. On a web server, it is particularly useful for the security of shared hosting accounts. When you set up a chroot jail, the name of the file you give it thinks that it is root, and there are no directories above it. The jail is secure as long as it can’t run as root.
During development of Version 7 Unix in 1979, the chroot system call was introduced and added to the Berkley Software Distribution (BSD). (chroot, 2011)
A chroot environment can be used to create and host a separate virtual copy of the software system to test software that might be too risky to deploy on a productive system. Software can be developed, built, and tested with its expected dependencies. Virtualized chroot jail can test compatibility with legacy software, and can assist with recovery if a system is unbootable.
In order for the chroot jail to work for a particular file, a copy of all the file dependencies must be present. This can be complicated depending on the file; without the file dependencies the file would be unusable.
It is possible to break out of chroot jail as long as the program is run with root privileges. For example, a script has been published to break out of jail using a C compiler or a Perl interpreter and security holes to gain root access. System patches that usually would fix the security holes in a security update would not know about the copies of the files in chroot jail. In order for the chroot jail to be maintained, system patches have to be applied to the chroot jail. It is very important that setuid (set user ID) binaries are not used in the chroot jail. When executing a file with setuid permissions, the process that executes the file takes on the permissions of the file owner. If that same file is owned by root, this enables an attacker to easily escape chroot jail. A security hole in a setuid can be used to compromise the security of the chroot jail. The chroot jailed file should also have the least privileges it can have and still be useable. Also, be sure that the user cannot access the executable files that are owned by root.. You can’t throw a file, a directory, or a process in the chroot jail and forget it, it will come back to haunt you. IPtaples and Netfilters work together in harmony on the kernel level the netfilter component is a group of tables that the kernel uses to control network packet filtering. On the user level, the iptables component sets up, maintains and displays the rules stored in netfilter. It was first used to configure the Linux 2.4.x and 2.6.x IPv4 packet filtering set of rules, and targeted towards system administrators.
The earlier versions of netfilter and iptables were called ipchains and ipnatcti. In the earlier stages, several people contributed some of the code, but it was mostly written by the core team. The core team was made up of Emeritus Members (no longer contributing) Paul “Rusty” Russell, Marc Boucher, and James Morris. Active members of the core team now include Patrick McHardy (head), Harald Welte, Jozsef Kadlecsik, Martin Josefsson, Yasuyuki Kozakai, and Pablo Neira Ayuso. Many others have contributed but not all have been elected to the team.
Netfilter is a set of hooks in the Linux kernel that allows the kernel modules to record callback functions with the network stack. For every packet that passes through the respective hook within the network stack a registered callback function is then called back.
Iptables is a generic table for the definition of a set of rules. Each rule within an Iptable consists of iptables matches (a number of classifiers) and iptables target (one connected action).
Together Netfilter, iptables, connection tracking (ipconntrack, nfconntrack) and the NAT subsystem build the major parts of the framework. (What is netfilter.org?).
The main features of iptables are stateless and stateful packet filtering for both IPv4 and IPv6, all kinds of network address (NAT) and port translation (NAPT) in IPv4 only, adaptable and extensible infrastructure, multiple layers of API's for 3rd party extensions, and a ‘patch-o-matic’ repository that holds a large number of plugins and modules.
Some of the things you can do with netfilter/iptables are build internet firewalls based on stateless and stateful packet filtering. If you don't have enough public IP addresses you would use NAT and masquerading for sharing internet access, to implement transparent proxies you would use NAT, aid the tc and iproute2 systems used to build sophisticated QoS and policy routers, and you can do further packet manipulation like altering the TOS/DSCP/ECN bits of the IP header. (What is netfilter.org?)
A secure iptables/netfilter machine relies on the rules that are programmed by the administrator. It is important to have a strong firewall ruleset and not let in just any internet traffic. There are hacks that let in packets from the web, using peer-to-peer software, by punching a hole in the firewall. (Vivek Gite, 2006)
Creating a viable secure operating system remains a critical research problem. In the open resource world of computing, many programmers are working on ways to create secure systems, and as soon as they do, many more hackers figure out a way to get around their security.