Linux security technologies and implementations

Linux Security Technologies

The continued popularity and rapid growth of open source software in general and the Linux operating system specifically are having a disruptive impact on proprietary software. The disruptive impacts of open source software are so pervasive that they are completely re-ordering the enterprise system strategies in many corporations globally today (Rooney, 2004). With this proliferation of open source software and the foundation being laid by the Linux operating system, there continues to be an urgent and escalating need for new security tools and applications and tools as well. Of the many security applications and tools available for the Linux operating system, the three that will be analyzed and assessed in this paper include chroot jail, iptables and SELinux. The analysis will include which organizations are sponsoring the development of each of these technologies, an explanation of how each of these technologies change the Linux operating system to make it more secure, and which types of threats each of these technologies are designed to eradicate and protect against.

chroot jail Evaluation

Originally designed and first launched in the initial release of Unix Version 7, which was first introduced in 1979, the chroot jail command limits which users have access to the root directories of UNIX. This is critically important from a system administration command standpoint, as the root directory access on a UNIX system can quickly re-order directory structures and en masse delete data and applications. During this timeframe the Berkeley System Division (BSD) UNIX was also very popular, and the vulnerability of root directory access was a very high security priority for commercial, educational and government organizations standardizing on this command. The chroot jail command was quickly integrated into the initial BSD releases due to the high priority customers of this operating system placed on its value from a security and system administration standpoint (Rooney, 2004).

There are many configuration and customization options for the chroot jail command, yet the most common use scenario is to control which user accounts have access to the root directory, / home/user directory. When this command did not exist any user could get to any location in the system, with full rights to edit, duplicate, delete or modify applications. As the UNIX kernel in Linux recompiles at application run-time, this could easily change which applications were working correctly or not (Rooney, 2004). This command also blocked unwanted access over networks connected to UNIX systems as well. Prior to this command it was possible for sophisticated users including hackers to traverse an entire network and gain access at the root level to any system they chose (Rooney, 2004). As of 2012, this command is being used to create development environments or sandboxes for testing applications and ensuring spurious or erroneous threads don't crash the system or harm other, more stable applications. This technology is now also pervasively used for creating network-wide application testing and validation for Web-based applications including social network platforms running on the Linux operating system.

SELinux Evaluation

This technology first was introduced in December, 2000 as part of the GNU GPL release, one of the most successful open source operating systems ever produced. The core technology of SELinux was invented by the U.S. National Security Agency (NSA) and commercialized for use so organizations could benefit from its many benefits. SELinux has significant support as a core technology in many distributions of the Linux operating system and its variants, including Linux kernel 2.6.0-test3 operating system (8/2003 release) (Greenemeier, 2005). The premise of this technologies' architecture is based on having the agility of a command that can control access points across user accounts, applications, integration points and user accounts through both UNIX and Linux operating system deployments is based on having the agility of a command that can control access points across user accounts, applications, integration points and user accounts through both UNIX and Linux operating system deployments (Greenemeier, 2005). What has also led to SELinux' greatest popularity however is the ability to tailor security policies and governance conditions for data access across each role on a network (Greenemeier, 2005). This is seen as extremely important for managing internal threats to UNIX and Linux systems while also [protecting against external threats by those who attempt tot hack into enterprise systems. This command is pervasively used in application development where the Linux kernel is compiled at runtime to ensure role-based authentication of data sets and use of specific applications (Greenemeier, 2005). In 2012 this technology is being incorporated into smartphones and tablet PCs to protect against unauthorized access to specific ports on these devices (Greenemeier, 2005). SELinux is a command that is designed to specifically address the concerns of system administrator's, IT Directors and Chief Information Officers (CIOs) concerned about protecting their enterprise-wide assets from unauthorized user internally and access externally.

Iptables evaluation

This technology is the direct result of a programmer at IBM seeing a major shortfall in the existing security in the Linux operating system. Like many other contributors to the Linux operating system, Rusty Russell, a programmer at IBM, took the initiative to create this command to avert potential security hacks via firewall deficiencies he discovered while programming TCP/IP-based applications and routines (MacVittie, 2005). What he found while programming network device drivers and communication software was the firewall code in previous Linux versions had only provided support for the UDP and ICMP commands of TCP/IP, yet not included legacy or expanded TCP/IP security parameter support (MacVittie, 2005). He also discovered that only 32-bit versions of the command were including in Linux legacy firewall support, and this represented a major risk to firewall comprehensive security levels as well (MacVittie, 2005).