Why shouldn't /var/www have chmod 777

Question

When developing a page on a localhost, I sometimes get a "Permission denied" error which I can solve by running chmod -R 777 /var/www. However, people are telling me that this is a bad idea for security reasons.

Why shouldn't /var/www have a chmod of 777?

Solution 1

777 is a bad permission in general and I'll show you why.

Despite how it may look in a Casino or Las Vegas, 777 doesn't mean jackpot for you. Rather, jackpot for anyone who wishes to modify your files. 777 (and its ugly cousin 666) allow Read and Write permissions (and in the case of 777, Execute) to other. You can learn more about how file permissions work, but in short there are three groups of permissions: owner, group, and other. By setting the permission to 6 or 7 (rw- or rwx) for other you give any user the ability to edit and manipulate those files and folders. Typically, as you can imagine, this is bad for security.

Here's my example:

marco@desktop:~/Projects/AskUbuntu/20105$ cd ..
marco@desktop:~/Projects/AskUbuntu$ chmod 0777 20105
marco@desktop:~/Projects/AskUbuntu$ cd 20105/
marco@desktop:~/Projects/AskUbuntu/20105$ ls -lah
total 8.0K
drwxrwxrwx 2 marco marco 4.0K 2011-01-04 20:32 .
drwxr-xr-x 3 marco marco 4.0K 2011-01-04 20:32 ..
marco@desktop:~/Projects/AskUbuntu/20105$ touch test
marco@desktop:~/Projects/AskUbuntu/20105$ chmod 0666 test 

So far I have created a folder and made a file with "bad" permissions (777 and 666). Now I'll switch into another user and try to manipulate those files.

marco@desktop:~/Projects/AskUbuntu/20105$ sudo su - malicious
malicious@desktop:~$ cd /home/marco/Projects/AskUbuntu/20105
malicious@desktop:/home/marco/Projects/AskUbuntu/20105$ ls
test
malicious@desktop:/home/marco/Projects/AskUbuntu/20105$ ls -lah
total 8.0K
drwxrwxrwx 2 marco marco 4.0K 2011-01-04 20:33 .
drwxr-xr-x 3 marco marco 4.0K 2011-01-04 20:32 ..
-rw-rw-rw- 1 marco marco    0 2011-01-04 20:33 test
malicious@desktop:/home/marco/Projects/AskUbuntu/20105$ touch bad
malicious@desktop:/home/marco/Projects/AskUbuntu/20105$ echo "OVERWRITE" > test 
malicious@desktop:/home/marco/Projects/AskUbuntu/20105$ cat test 
OVERWRITE

As this "malicious" user I was able to place files into the directory and inject text into already existent files. Whereas below, in a directory with 755 and files with 644, I am able to see inside files and directories but I can not edit the files nor create new ones:

malicious@desktop:/home/marco/Projects/AskUbuntu/20105$ cd /home/marco/Projects
malicious@desktop:/home/marco/Projects$ touch hey
touch: cannot touch `hey': Permission denied

For Apache permissions, you're going to want to stick to 0755 and 0644 (AKA umask 022) for folders and files respectively. This allows you, as the owner of the files, to edit and manipulate them while giving Apache the bare minimum levels of access needed to operate.

Solution 2

Essentially, having permissions of 777 are not going to get you hacked on their own, but if someone gets a toehold in anywhere at all, it can be used to escalate permissions and gain complete control over your computer. The worst part is that your permissions are using "7" - that means read, write, and execute permissions.

Let's say a hacker wants to take over your computer. He might connect to your computer using a web browser, connecting to http://yourcomputer.example.com:80/ . If you have any pages available that let him upload images, he can rename an executable to end with ".jpg" and upload it to your server. Now he browses to that file in his web browser and runs it, because linux doesn't care about the extension, it only sees that it's an executable file. That may not get him much, but because it ran at all, he knows it ran as the apache user. He then uploads a modified version that will edit apache's config files, granting him even more access - let's say so that apache will output the contents of /etc/passwd. He can then use that information to see what users exist on the system. He can then connect using ssh and try common passwords to log in as those users - if that doesn't work he'll step up to using a full brute-force attack. If he gets in as a user with sudo access, then the entire system is his.

Now, you may say that's not likely, or that it's not how a real hacker would work. That is true, but the point is that by setting files to be chmod 777, you've opened a security hole that a hacker can use however he sees fit.

If you instead follow the Principle of least privilege, then that hole doesn't occur, and your system is that much harder to hack. Even though it's more difficult to do things properly, you should still make every effort to do so.

Comments

[Luis Alvarado]

I am sorry for the language but this is a kick-ass answer. Thank you Marco.

[Nicholas Jordan]

What if you only have created users for the people that are allowed to manage the /var/www folder freely? I use dedicated Virtual Machines for each webserver that I run, and I wonder if it still holds true that you should be so careful.

[Michael Gundlach]

@UrkoM You can never be too careful. If you want people to access the same files you can bump up the group permissions to 6/7 (0664/0775) and add each user to that group. While this setup (and the one I described in my answer) don't meet every criteria I would say a good 90% of the time 0755/0644 are the permissions you'll want to use. If you only have "one user" systems then the risk of have other with write permissions isn't as much a risk.

[Eliah Kagan]

@UrkoM The other thing to consider is that there are a lot of "users" who don't represent real people but exist so that certain services can run with reduced abilities (mainly for security reasons, but also to reduce the harm that could occur from a stability bug). View the contents of /etc/passwd and you'll see users like mail, news, and nobody. Even if it's fine for all the real human users of your system to be able to modify the contents of /var/www, that doesn't mean you want all processes run as these "artificial" users to be able to do so.

[Kari Kääriäinen]

+1 for "toehold" and "escalate". Describes the concept well.

[Garri Sumalapao Farol]

1) As the simplest answer as can be. Doesn't explain how Apache or Nginx can manipulate folders or files. Apache or Nginx are servers, so that applications, they are not your "malicious" user, they cannot type ls -lah, touch bad or any other commands. How can they manipulate folders and files? 2) Inheritance. You didn't cover any inheritance between folders and files within them. There are at least 2-3 step before a file: /var, /var/www, /var/www/project. What user/group permissions should /var have? What user/group permissions should /var/www have? And so on. How they cooperate?

[Anurag Peshne]

Can you please explain how a file disguised as jpg can be executed on a server?