Greetings, gentle reader, and welcome to linuxsecurity.com and our new recurring series of articles on security related mistakes and how to avoid them. I'm your host, Pax Dickinson, and today we'll be reviewing basic Linux file and directory permissions and how to avoid some common pitfalls in their use, in this episode of Hacks From Pax.

One common mistake Linux administrators make is having file and directory permissions that are far too liberal and allow access beyond that which is needed for proper system operations. A full explanation of unix file permissions is beyond the scope of this article, so I'll assume you are familiar with the usage of such tools as chmod, chown, and chgrp. If you'd like a refresher, one is available 49 on linuxsecurity.com.

I've witnessed systems administrators whose response to a user complaining about being denied access to a given file is to chmod 777 the file (or entire directory tree) in question. This is an absolutely disastrous security practice, the administrator has just granted write access to the file to any user on the system. Any compromised service will allow an attacker to modify the file, which could result in further access depending on the file in question. For example, an attacker gaining write access to a script that is occasionally run by root can parlay this seemingly minor security hole into full root access for himself.

  • Never make files world-writable. Most files do not need to be world readable either.

  • You can search for world-writable files under your current directory by issuing the following command:

    find . -perm -2 -print

A related mistake is in the misuse of suid root binaries. These are programs which can be launched by a user but run with all the privileges of root. These programs are needed to perform tasks such as changing a user's password, since that requires a write to the system's password file which normally cannot be modified by anyone but root. A flaw that allows an attacker to gain a shell prompt in such a program can give an attacker root access to the system. These binaries should be carefully limited and must be kept up to date with appropriate security patches to minimize their risk. A common backdoor installed by successful attackers is a copy of /bin/sh set suid root. This can be run by any user on the system, without a password, and will result in full root access.

Suid root bits should never be set on a shell script, as they are impossible to make secure. In fact, because of their insecurity, modern versions of Linux do not allow their use and will not respect the suid or sgid bits on shell scripts.

  • Don't try to make shell scripts suid root. If you must, investigate suidperl, which is safer but still should be used carefully and only when absolutely necessary.

  • You can search your system for suid and sgid files by issuing the following command:

    find / -type f -perm +6000 -ls

A close eye should also be kept on the file permissions within the /dev directory. Improper permissions here can allow users to read or write directly to hardware devices such as hard disks and network interfaces. Most devices should only be writable by root, and readable only by the group they belong to, with the exception of terminal devices (/dev/tty and /dev/pty), /dev/null and /dev/zero. Generally device files only exist within the /dev directory, but this is not required. An attacker my attempt to replicate a device file outside of this directory in order to gain access to otherwise protected data.

  • You can search the /dev directory for world writable files by issuing the following command:

    find /dev -perm -2 -print

  • You can locate all device files on your system by issuing this command:

    find / ( -type b -o -type c -o -type s -o -type p ) -ls

As you can see, the find command is extremely useful for keeping an eye on the file permissions of your system. A script that runs several find commands can be launched by cron periodically to monitor your file permissions. Combining this with an intrusion detection system, discussed later in this series of articles, will help you both implement and maintain a high security environment. It may be a cliche to say this, but security truly is a process and absolutely requires an ongoing commitment.

Stay secure, and I'll see you soon, in the next episode of Hacks From Pax!
--
Pax Dickinson has over ten years of experience in systems administration and software development on a wide variety of hardware and software platforms. He is currently employed by Guardian Digital as a systems programmer where he develops and implements security solutions using EnGarde Secure Linux. His experience includes UNIX and Windows systems engineering and support at Prudential Insurance, Guardian Life Insurance, Philips Electronics and a wide variety of small business consulting roles.