IT 302

SELinux

SELinux is a security enhancement to Linux which allows users and administrators more control over access control. Access can be constrained on such variables as which users and applications can access which resources. These resources may take the form of files. Standard Linux access controls, such as file modes (-rwxr-xr-x) are modifiable by the user and the applications which the user runs. Conversely, SELinux access controls are determined by a policy loaded on the system which may not be changed by careless users or misbehaving applications.

The United States National Security Agency, the original primary developer of SELinux, released the first version to the open source development community under the GNU GPL on December 22, 2000. The software merged into the mainline Linux kernel 2.6.0-test3, released on 8 August 2003. Other significant contributors include Network Associates, Secure Computing Corporation, Trusted Computer Solutions, and Tresys Technology. Experimental ports of the FLASK/TE implementation have been made available via the TrustedBSD Project for the FreeBSD and Darwin operating systems.

SELinux also adds finer granularity to access controls. Instead of only being able to specify who can read, write or execute a file, for example, SELinux lets you specify who can unlink, append only, move a file and so on. SELinux allows you to specify access to many resources other than files as well, such as network resources and interprocess communication.

A Linux kernel integrating SELinux enforces mandatory access-control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. This reduces or eliminates the ability of these programs and daemons to cause harm when compromised. 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. The security of an "unmodified" Linux system depends on the correctness of the kernel, of all the privileged applications, and of 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 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. From a purist perspective, SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls, mandatory integrity controls, role-based access control (RBAC), and type enforcement architecture. Third-party tools enable one to build a variety of security policies.

Chroot Jail

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. Without a chroot jail, a user with limited file permissions would still be able to navigate to top-level directories.

Another important use for chroot is for virtualization. With a virtual private server, the user has a complete operating system installed within a chroot directory. As a result, even though the user has root privileges for his or her own account, the user cannot access higher directories and would not even be aware that they exist. In other words, if the user is in /var/chroot/vhosts/user/, there is no way to move up beyond that /user directory. It will appear to the user as the default root directory, which is /. Chroot is very useful for basic preventative security, but it is not designed to prevent deliberate attempts to gain root access and attack a server. For that there are other security measures you can take. Nevertheless, chroot helps tremendously to at least make it more difficult to exploit your dedicated server. A chroot jail presents a dramatically restricted view of the filesystem to an application, and usually far fewer system privileges, and this all intends to limit the damage should the application go awry or be subverted by the bad guy. The chroot system call changes the root directory of the current and all child processes to the given path, and this is nearly always some restricted subdirectory below the real root of the filesystem. This new path is seen entirely as "/" by the process, and we refer to this restricted environment as the "jail". It's not possible to escape this jail except in very limited circumstances. The chroot system call is found in all versions of UNIX that we know of, and it serves to create a temporary root directory for a running process, and it's a way of taking a limited hierarchy of a filesystem (say, /chroot/named) and making this the top of the directory tree as seen by the application.

Iptables

Iptables is a user space application program that allows a system administrator to configure the tables provided by the Linux kernel firewall and the chains and rules it stores. Different kernel modules and programs are currently used for different protocols; iptables applies to IPv4, ip6tables to IPv6, arptables to ARP, and ebtables to Ethernet frames.

All Red Hat Enterprise Linux versions, unless specified, come with iptables installed and started automatically the first time you turn on your server. There just may not be any rules to abide by. If there are no rules to follow, then iptables will not do anything with the network packets. It will act as if there is no firewall at all. Iptables requires elevated privileges to operate and must be executed by user root, otherwise it fails to function. On most Linux systems, iptables is installed as /usr/sbin/iptables and documented in its man page, which can be opened using man iptables when installed. It may also be found in /sbin/iptables, but since iptables is more like a service rather than an "essential binary", the preferred location remains /usr/sbin.

Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user-defined chains. Each chain is a list of rules which can match a set of packets. Each rule specifies what to do with a packet that matches. This is called a ‘target’, which may be a jump to a user-defined chain in the same table.

A firewall rule specifies criteria for a packet, and a target. If the packet does not match, the next rule in the chain is the examined; if it does match, then the next rule is specified by the value of the target, which can be the name of user-defined chain or one of the special values ACCEPT, DROP, QUEUE, or RETURN.

ACCEPT means to let the packet through. DROP means to drop the packet on the floor. QUEUE means to pass the packet to userspace (if supported by the kernel). RETURN means stop traversing this chain and resume at the next rule in the previous (calling) chain. If the end of a built-in chain is reached or a rule in a built-in chain with target RETURN is matched, the target specified by the chain policy determines the fate of the packet.