Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Sign up!
EnGarde Community
What is the most important Linux security technology?
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Latest Newsletters
Linux Security Week: March 30th, 2015
Linux Advisory Watch: March 27th, 2015
LinuxSecurity Newsletters
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

Hacks From Pax: Linux File & Directory Permissions Mistakes Print E-mail
User Rating:      How can I rate this item?
Source: Pax Dickinson - Posted by Administrator   
Features Greetings, gentle reader, and welcome to 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 right here on

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.

Permission QuestionWritten by Joe on 2006-04-20 20:38:37
Sorry to bother you but quick question - coming from the Solaris world as root one can "lock down" a users .profile - meaning the user can read it but can't change it - this doesn't work on Linux. 
Root can 444 root:root the file but the user can change it BUT if root adds a directory as root into the users home account the user can't delete chown etc it. Seems a little strange - how does root lock down a users .bash_profile then? Thanks 
my mail to_shailesh_solanki@yahoo.comWritten by shailesh on 2006-06-23 05:15:51
well, this is fine, But can you find the system directory in linux like c:\winows in system
what about foldersWritten by pritesh on 2006-07-02 20:01:36
I read thru ur posting and i changed all 777 to 666. But there is a folder at 777 in which i get users to upload content. Is this safe. when i set it to 666, the upload stops working.
Root permissionsWritten by Allison on 2007-04-06 15:12:42
I'm just learning Linux and I need to know if I have a directory called dept_share that I only want root to be able to write to and all users to be able to enter and list will rwx---r-- work. 
Thanks. ;)
Need to secure /dev locationWritten by Roy on 2007-09-04 09:32:34
I noticed your article say's that with the exception of "terminal devices (/dev/tty and /dev/pty), /dev/null and /dev/zero", when I look I see this wrong? 
lrwxrwxrwx 1 root root 3 Aug 13 03:14 cdrom -> hda 
lrwxrwxrwx 1 root root 3 Aug 13 03:14 cdrom1 -> hdf
soemthing a bit wrongWritten by sk on 2007-11-02 11:53:47
IS it me or is there something dreadfully wrong with a security website having spam in it's forums.....
Remove permissionWritten by Sukrutha Kini on 2008-06-18 03:39:48
How to remove world-write permissions of the device files

Only registered users can write comments.
Please login or register.

Powered by AkoComment!

< Prev   Next >


Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2015 Guardian Digital, Inc. All rights reserved.