Security-Enhanced Linux System - Research Paper Example

SECURITY-ENHANCED LINUX Table of Contents Table of Contents INTRODUCTION 2 DISCUSSION 4 CONCLUSION 8 FIREWALL CONFIGURATION 9 REFERENCES 14 INTRODUCTION In the modern information age, one is aware of the ongoing battle between proprietary software providers and open source initiatives with each trying to vie over the other in an effort to gain control of the software market. While the traditional profit seeking proprietary vendors have been building their presence over the years through sound branding and marketing, the people involved in open source initiatives have succeeded in gathering a relatively commendable group of dedicated enthusiasts who are passionate about software and who believe that it must be available to everyone for free. Over the years, despite the availability of hundreds of amazing open source tools, one name has captured both the imagination and awe of everyone, irrespective of what they ultimately support. Linux-the use of the name brings to mind two major things, one is free software and the other is Linus Torvalds, who conceived the idea of providing an operating system to users for free and succeeded in initiating and sustaining a whole movement behind his vision. Over the years, Linux has been made available in different flavors and users have been innovative in using the freely available source code to modify and use according to the requirement at hand. Various issues such as speed, adaptability, resource usage, embedded systems, distributed computing and complex analysis have served as major purposes that have enabled Linux to be developed in different ways. However, one of the most important purposes of developing Linux towards future versions has been with a view to providing greater security in the midst of an internet riddled with hacks and exploit by unscrupulous elements. One such attempt was the create a security architecture that would combat all known issued involving security with Linux as the foundation (Bill McCarty, 2005). Thus, security-enhanced Linux or SELinux was born. The next section will elaborate further on the topic. DISCUSSION In the modern age the Internet, which is becoming every increasingly accessible with the introduction of high speed networks, and with the explosion in the growth and use of wireless networks (Wi-Fi), gaining unauthorized access has become an easy task. One can use simple tools such as aircrack and easily guess the passkey to a Wi-Fi network simply by analyzing encrypted packets and performing a brute force attack. In such a scenario, preventing unauthorized access to sensitive information has become a very important issue, which has been given due recognition by individuals, corporations and even governments owing to the sensitivity of the information that they sometimes have to deal with. In order to answer the serious concerns raised by such security issues and due to existing deficiencies in software technologies, the National Security Agency of the US Government, referred to as NSA in short, teamed up with members of the Linux community in order to devise a secure access control architecture that would restrict processes to only those resources such as files that were required by them in order to perform their operations (Matthias Kalle Dalheimer & Matt Welsh, 2003). In fact, a series of security policies were defined and implemented at the Linux kernel level itself, so that security could be managed from the lowest levels possible. The version of the Linux kernel that was made available with these set of security policies in place is now popularly known as Security-Enhanced Linux or SELinux in short. SELinux provides security through the provision of Linux Security Modules (LSMs) that establish access control. As such, SELinux cannot be regarded as a separate Linux distribution, but rather a modified version of Linux with better safeguards (Richard Petersen, 2005). As has been mentioned before, SELinux works on the concept of Mandatory Access Control (MAC), which is in turn based on the domain-type model. The domain type model is an improvement over the existing Linux kernel, comprising of required security patches that are applied to certain applications and an overall security policy in addition to the kernel itself, which is itself augmented by the access modules specified above. The difference between this approach and the traditional Unix based access mechanism is clearly evident from the fact that in the earlier model, there was no superficial control over the control of a process over its resources and neither was there any additional control apart from the standard read, write and execute rights. As such, every process was able to grant access rights at will without interference from any other external processes. MAC has changed all that and works as a governing body by providing access rights that dominate over the regular access granted by a process. This provides an additional benefit by allowing the administration of the files which a process can have access to, thereby providing a known mechanism for troubleshooting security related issues. Additionally, such a policy measure allows restricting programs from writing to and granting permissions to each other as it allows one to specify which files a program can access and what level of access may be granted to it (Everett F. Carter, Jeremy Faircloth & Curtis Franklin, 2003). The deviation from the traditional access approach can be explained by the fact that in the case of the latter, it would have been impossible to deny delete rights while simultaneously allowing a program to create and edit files. The traditional approach does not provide a fine-grained mechanism, while SELinux allows a user to grant rights that govern discrete operations such as appending, editing, rewriting and truncating. SELinux also provides access control across networks by granting access or deny permission to a set of ports or network adapters that a program may be able to access. The domain model implies that every process is visualized as performing within the confines of an individual security cocoon that has a previously specified set of resources with a centrally controlled access to every resource. Every domain is thereby comprised by a policy that defines the set of actions that it may perform (Christopher Negus, Chris Negus, 2002). One of the most significant advantages of using such an approach is that it allows the clear and speedy verification of the different interactions that can be related with the application, which have proven to be time saving when troubleshooting issues. this is because such a specification provides a clear explanation of every single aspect related to the process and assures the troubleshooter that they do not have to examine any additional resource while trying to solve an issue, thereby facilitating in speedy identification and plugging of deficiencies. The policies are maintained by a SELinux policy database that conducts and maintains all features of the SELinux installation. It specifies the domain associated with each program as well as the different types that the domain may access by way of a policy. A policy is a collection of rules that provide the specifics of the policy. All such policies can be controlled through an interface based administration console. There is also a default policy in place that ensures a standard way of operation for most common users. This may include permissions as to whether users will be able to read kernel level and system level logs using standard commands, or whether a particular user can access a specific folder in the environment. In addition, these permissions may be modified by the administrator at will. A typical policy database is governed by as many as 100,000-250,000 rules, which are operated by using macros. These rules occupy anywhere between 5-10 MB of memory. Such a high use of memory implies that SELinux has not been fine tuned with regards to minimum memory usage. As such, the inclusion of additional rules may prove to be an added overhead over the kernel memory (Michael Jang, 2001). One of the most elegant features of SELinux is that it helps the user understand administration policies at the process level is terms of just 3 simple components namely – identity, role and domain. Identity under the current context refers to the user login that recognizes the individual or system process that is currently invoking the process (remember processes can invoke other processes as well). The role acts as mappings between identities and domains by specifying the domains that are allowed to be associated with a particular identity. All the three classes of access can be controlled via the administration console (Frank Mayer, David Caplan & Karl MacMillan, 2006). As such, SELinux provides a clear distinction between policy definition and enforcement by the provision of suitable interfaces. Users will have the added advantage of querying the policies applicable at an application level to determine if they can access the application for specific purposes. What makes the approach even more lucrative is that every policy has an inherent identity and is applicable for objects even at the kernel level. However, there have been certain issues with regards to speeding up the verification of access rights during the instance of invoking an application as a number of rules must be verified before the adequate access rights can be determined. A solution with a view to speeding up this process has been to allow all such queries to be cached so that they may be queried during subsequent accesses thereby enabling quicker access. There is an excellent support for editing policies and adequate steps have been taken to ensure system integrity and coherence with the traditional access policies used by individual applications. What is even more interesting is that SELinux provides enhanced control over individual stages of a process’ lifecycle, such as during initialization, execution and inter-process communication. SELinux provides access control over different types of resources. Apart from functioning at the kernel and process level, security is also configurable for files, directories as well as their metadata (by allowing file descriptors to be configurable) as well as networks, sockets and connections (Terry Collings & Kurt Wall, 2007). However, the effort into SELinux is still in its very early stages and requires research into many more areas, before it can be deemed as a standard solution. For example, SELinux currently lacks support for polyinstantiated network ports (parallel single-level network connections) and directories. NSA has further cited that it there is much work to do in providing control over the network file system (NFS). Another area that is gaining adequate attention is the provision of heterogeneous policies unlike the existing entity-level homogeneous rules, which will in turn complicate rule specification and policy administration (Roderick W. Smith, 2005). People have also voiced their concern over the imposed restriction on network scalability as a result of adopting the domain level approach. CONCLUSION The above paragraphs were a brief introduction to the pros and cons of using SELinux in a volatile and insecure environment. It is evident from the above arguments that SELinux has taken policy administration into a completely different league, which has raised further questions. As such, users await with eagerness as to what the subsequent versions of SELinux will be equipped with that will augment the dual requirements of strengthening security and easing the burden on the administrator. FIREWALL CONFIGURATION The approach to the firewall iptable script is as explained below: a) Full egress & ingress filtering. Egress/Ingress filtering are firewall configuration options that help secure the system against Denial of Service attacks across a network. While ingress filtering monitors the traffic that enters a network, egress filtering controls the traffic leaving the network thereby preventing any information from getting out (Robert L. Ziegler, Carl B. Constantine, 2005). As part of ingress filtering, no packet containing a private IP address must be allowed into the network. On the other hand, egress filtering monitors outbound traffic by checking for the source address, preventing packets that do not contain an IP address of the owned network as the source address. This helps in securing sensitive information concerning the network infrastructure from reaching outsiders (Michael Rash, 2005). b) The machine has only network connection eth0 This means that the machine is connected only to a single external network through the connection eth0. c) The machine runs ssh, telnet, apache and qmail. This shows that the application runs in a secure environment where all the communication is encrypted. Also, the use of telnet, apache and qmail points to a constant communication across the external network. As such, the primary tasks under network communication are surfing the web, accessing email and performing DNS lookups. d) The apache user should not be allowed to surf the web. The iptable firewall script is as shown below: #!/bin/sh # Variables associated with our network # IP is the IP Address of the machine # NETIP is the IP Address of the network IP= 125.356.223.014 NETIP= 125.356.223.0/24 ETHERNET="eth0" # Assume that the machine queries a DNS Server with the following IP Address #instead of querying the nodes directly DNS=212.456.234.142 # Set the policy to be DROP. # If a packet does not match any of the rules, # it will be discarded. # this script will run before the flush #in order to ensure that the inner network is secure # as long as the script runs iptables -P INPUT DROP iptables -P OUTPUT DROP # Flush iptables. iptables -F iptables -F INPUT iptables -F OUTPUT # allow all packets that originate and are destined withing the local network. iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Drop incoming packets that contain local network address. iptables -A INPUT -i $ETHERNET -s $IP -j DROP # Drop outgoing packets that do not contain local network address. iptables -A OUTPUT -o $ETHERNET -s ! $IP -j DROP # block packets with private IP Addresses such 172.168/16, 192.168./16 # Allow inbound HTTP from everywhere iptables -A INPUT -i $ETHERNET -p tcp -d $IP --dport 80 -j ACCEPT iptables -A OUTPUT -o $ETHERNET -p tcp -s IP --sport 80 ! --syn -j ACCEPT # Allow SSH iptables -A INPUT -i $ETHERNET -p tcp -d $IP --dport 22 -s $NETIP -j ACCEPT iptables -A OUTPUT -o $ETHERNET -p tcp -s $IP --sport 22 -d $NETIP ! --syn -j ACCEPT # Allow telnet for outbound queries Iptables -A INPUT -o $ETHERNET -p tcp --dport 23 -j ACCEPT # Allow email (SMTP) iptables -A INPUT -p tcp -i $ETHERNET --dport 25 -j ACCEPT      iptables -A INPUT -p udp -i $ETHERNET --dport 25 -j ACCEPT # Allow packets for DNS queries iptables -A OUTPUT -o $ETHERNET -p udp -s $IP --dport 53 -d $DNS -j ACCEPT iptables -A INPUT -i $ETHERNET -p udp -d $IP --sport 53 -s $DNS -j ACCEPT # Log all errors to syslog iptables -A INPUT -j LOG iptables -A OUTPUT -j LOG REFERENCES 1. Michael Jang (2001), RHCE Red Hat Certified Engineer Linux Study Guide. New York: McGraw Hill. 2. Christopher Negus, Chris Negus (2002), Linux Bible. london: John Wiley. 3. Terry Collings, Kurt Wall (2007), Red Hat Linux Networking and System Administration. London: John Wiley. 4. Roderick W. Smith (2005), Linux+ Study Guide. London. 5. Michael Rash (2005), Linux Firewalls. London: No Starch Press. 6. Matthias Kalle Dalheimer, Matt Welsh (2003), Running Linux. 7. Bill McCarty (2005), SELinux. University of Michigan. 8. Richard Petersen (2005), Linux. New York: McGraw Hill. 9. Everett F. Carter, Jeremy Faircloth, Curtis Franklin (2003), Hack Proofing XML. New York: Syngress. 10. Frank Mayer, David Caplan, Karl MacMillan (2006), SELinux by Example: Using Security Enhanced Linux. London: Prentice Hall. 11. Robert L. Ziegler, Carl B. Constantine (2005), Linux firewalls. Boston: Sams publishing. Read More