Secure file permissions

Using Secure File Permissions

This document is intended to help users understand and thoughtfully set permissions on their files. Having insecure permissions can allow malicious users to do anything from reading or replacing your files, editing your work (without you being aware of it), to executing programs under your account.

Are my file permissions secure?

This question is generally best answered by yourself with a bit of knowledge about what's going on. For that, read the File Permissions overview FAQ first. However, there are some commands you can run to do a rough sanity check on your file permissions. For fully understanding their meaning, I suggest you read the manual page for find. NOTE: In most of the examples, the find command is executed on the current working directory ( . ), rather than the home directory explicitly ($HOME). This is so that you can use them in any directory with a simple cut and paste. To help remind you that they are for use in the home directory, there is a cd command before each. cd without any arguments will change to your home directory.

Minimal Access on Home Directory

Your home directory itself should have little or no access. Particularly, it shouldn't have read or write access for anyone besides the owner. $ ls -ld $HOME drwxr-xr-x 105 jsmith jsmith 8192 Mar 11 15:01 /import/server/1/jsmith $ chmod 711 $HOME/ $ ls -ld $HOME drwx--x--x 105 jsmith jsmith 8192 Mar 11 15:01 /import/server/1/jsmith

Nothing world writable

First we change to the home directory, or directory you want to check. The second command checks the current directory and all its children for files that have the "write" bit set in the other/world class of permissions, ignoring symbolic links (which are the only type of file for which world permissions are not a problem). $ cd $ find . -perm +002 ! -type l -ls 14008420 0 -rwxrwxrwx 1 jsmith jsmith 42 Mar 9 13:33 ./unsafefile It has found an unsafe file! This is a bad one, since anyone can change its contents! You can see the permission string as the third field of the output. This command finds all world writable files and uses chmod to remove that access: $ cd $ find . -perm +002 ! -type l -exec chmod o-w {} \;

Nothing outside of your public_html should be world readable or executable

This is true in most cases. There are a few instances where you may want to make a program or file available to everyone else, but you should know exactly which ones these are anyway. Your public_html gets a special exclusion, because files on your website generally need to be world readable for the web server to access and display them. If you have a website, your home directory itself also needs to be world executable (but no more!). $ cd $ find . -path ./public_html -prune -o -perm +007 ! -path . ! -type l -ls 15089686 4 -rw-r--r-- 1 jsmith jsmith 477 Feb 3 16:59 ./somefile Here we search for the world read, execute or write perms, but not inside public_html and not symlinks. The results show us that somefile is world readable and probably shouldn't be. Correcting this can just use a similar method: $ cd $ find . -path ./public_html -prune -o -perm +007 ! -path . ! -type l -exec chmod o-rwx {} \;

All directories in your public_html directory should be executable only

If a directory in your public_html is readable, people (including the webserver!) can see its contents. $ cd $ find ./public_html -type d -perm +006 -ls 16973841 4 drwxr-xr-x 2 jsmith jsmith 4096 Jan 14 18:32 ./public_html/misc Here we see that the misc directory in public_html is world readable. In most cases, we don't want or need world read in public places, so we clean all of them up: $ cd $ find ./public_html -type d -perm +006 -exec chmod o-rw {} \;

All files in your home directory should be owned by you

This is a security check to make sure other people haven't put files into your directory at some point. $ cd $ find . ! -user $USER -ls 14008508 4 -rw------- 1 root jsmith 204 Jan 14 10:36 ./.onetimepassword 3850281 4 -rwx------ 1 ev1ld0er jsmith 3356 Dec 10 14:57 ./tmp/nastiness $ This is just looking for any file that isn't owned by you. You can do a similar check for group ownerships - just replace -user with -group. The example shows the .onetimepassword file. This is actually ok - it is created by the otpasswd command. You can probably trust things that are owned by root - that is the system administration super-user. There is another file, owned by ev1ld0er. It isn't even readable by you! If it concerns you, you should contact HelpDesk or System Support. If you know where it is from, trust it, and don't need it anymore, just delete it (but you can't change the ownership directly, only root can).

What are reasonably safe default permissions?

If you do not intend to publicise files, then the following guidelines for default permissions should do the trick: Set your umask to 077. If you're using the "bash" shell (the default shell), add umask 077 to your ~/.bashrc file. This will make files created by default without any access for other people. You can then "opt-in" the files that need increased permissions. The following list is in increasing order of access. * Regular files should be mode 600 (user read/write only). * Executable files should be mode 700 (user read/write/execute only). * Directories should be mode 700. * Your home directory should be mode 711 (so that the web server can reach your public_html). * Your public_html should be mode 711. * Public files should be 644 for general read, or 755 if execute is needed. * A directory containing public files should be mode 711. * A public directory should be mode 755 (i.e. you want a user to be able to list all contents). Remember - don't give more access than you need. If in doubt, choose the mode nearest the top of the above list. *Notes* It is worth noting that just because a file appears in the above list doesn't mean it is currently insecure. If the restrictions on the parent directory are strong, then the files inside it should be safe. Nevertheless, if everything has the right permissions, you won't have to worry so much about forgetting to fix up file permissions if you move a file out of a secure tree.
Last edited by Kam Hoong Cheong 14/04/2011

Tags for this page:

file, permissions, security