The kernel, root and setuid

The Linux kernel and security

As the heart of the operating system, the kernel is a critical component of the security of your computer. A bug in areas like the filesystem code could easily be exploited, but fortunately, there are very few instances of major security holes in the Linux kernel.

It is critical that the kernel be kept up to date: not only do you enjoy the benefits of enhanced stability, features and speed, but also enhanced security.

It is also important that you carefully check the source of any patch for the Linux kernel. There have been instances of people releasing patches that have caused security holes. Caveat emptor (except it's a free operating system).

The root of all evil

The super-user has complete control over a Linux box: an admirable target for your average cracker. Some suggestions for minimising the chances of this happening:

  1. One person should have access to the root password: the owner or system administrator of the computer.

  2. If other people need to carry out tasks that require the root password, use sudo.

  3. Use (or create) a wheel group for trusted users that grants them certain privileges: the right to use sudo, read access to system logs, etc.

  4. Don't telnet into your Linux box as root! Use ssh.

Setuid/setgid programs

Setuid root programs grants a program access to root privileges, even if the user is not root. Some examples include DOSemu, DOOM, lpr and sendmail, all of which have well-documented exploits that give users root privileges.

A very large number of security holes come from stupid programming errors in SUID programs. At the very least:

  1. Minimise the number of SUID/SGID programs on your system

  2. Set up a group specifically for each program. For example, create a dos group for trusted users of DOSemu to prevent malicious users exploiting DOSemu to gain access to I/O ports, and, from there, the hard drive.

You can also set up non-setuid root programs with their own ownership and group so that if the program is compromised, an attacker can do little damage. For example, a web server running as nobody in the nogroup group will not be able to read the shadow password file or write to users' home directories. Entries for these groups can use /bin/true for the shell and use /tmp for their home directory.

For example, the UUCP programs have their own owner and group to minimise the effects of any malicious exploits:

From /etc/passwd


Prev | Home | Next