Hi,
I have a series of websites hosted on two CentOS 7 servers, using Apache virtual hosts. One of these servers is a "sandbox" machine, to test things and to fiddle around.
On the sandbox server, I have a few dummy websites I'm hosting.
# ls /var/www/html/ default phpinfo slackbox-mail slackbox-site unixbox-mail unixbox-site
Since Apache is running as system user 'apache' and system group 'apache', I thought it sensible that hosted files be owned by that process.
# ls -l /var/www/html/ total 24 drwxr-x---. 3 apache apache 4096 6 juil. 09:37 default drwxr-x---. 3 apache apache 4096 6 juil. 10:01 phpinfo drwxr-x---. 3 apache apache 4096 6 juil. 09:41 slackbox-mail drwxr-x---. 3 apache apache 4096 6 juil. 09:37 slackbox-site drwxr-x---. 3 apache apache 4096 6 juil. 09:42 unixbox-mail drwxr-x---. 3 apache apache 4096 6 juil. 09:38 unixbox-site
Directories are all drwxr-x---, while files are -rw-r-----.
Now some guy on the french forum fr.centos.org told me that I got everything wrong, and that my setup is a security flaw, without elaborating any further though.
So I thought I'd ask on this list (which is a little bit more urbane than the french forum).
1. What is wrong with my setup ?
2. What do you suggest ?
BTW, I don't mind to RTFM, even extensively.
Cheers from the sunny South of France,
Niki Kovacs
Possibly what he means is that having the files and directories writeable by the process that the web server runs as is a security issue. i.e. if there are any security issues with httpd, or the code that runs on the sites, then without a privilege escalation the exploit would run as the apache user, which means that the exploit can write to those directories resulting at the least a defaced site or at worst the upload of a more problematic exploit.
Have as few directories/files owned by the web server process as possible. If you have an application that needs to write to a file or upload to a directory, then they do need to be owned & writeable by apache.
The files do need to be readable by the apache user, so the file permissions are usually 644 (with directories 755) and owned by root.root - although the actual owner doesn't matter so long as apache can read the files. I suppose if you are really paranoid, then set the owner to nobody.nobody
BTW, I don't mind to RTFM, even extensively.
There's lots of pages out there about hardening Apache and what file ownership and permissions the site should have. Everyone has their opinion and the defaults for different distros varies. But the underlying idea is that the web server files should not be owned by the process that the web server runs as.
P.
Le 07/07/2017 à 12:53, Pete Biggs a écrit :
Thanks very much. I just updated the relevant information on my blog.
https://blog.microlinux.fr/apache-centos/
https://blog.microlinux.fr/apache-ssl-centos/
Cheers,
Niki
On Friday, July 7, 2017 5:25:29 AM CDT Nicolas Kovacs wrote:
Hi Niki -
Pete Biggs has weighed in with one way of setting Apache permissions. His basic contention is right on: The user under which the Apache process runs should not have write permissions.
The method we adopted at my last job goes like this: All of our CentOS7 servers are members of Active Directory. We created an AD group which contains the user names of our web developers. We do not have any Web services that require writing data back to the server, so we do not have that complication to deal with. We also have nothing that writes to a database.
On the CentOS server everything is owned by nobody and has a group of devs@ad.com.
chown -R nobody:devs@ad.com /var/www/html
File permissions are 574. Note that owners are NOT required to have higher permissions than groups!
find /var/www/html -type f -exec chmod 574 {} ;
Directory permissions are 575. The eXecute bit must be set so that Apache can navigate into the subdirectories.
find /var/www/html -type d -exec chmod 575 {} ;
The group sticky bit is set on directories. That means any new directories created by the developers will have a group of devs@ad.com.
find /var/www/html -type d -exec chmod g+s {} ;
We also set ACLs on the directories so that new files and directories have the desired permissions. I don't remember the exact command for that. Setfacl is pretty finicky!
The end result can be a bit messy since new files in the html directory will be owned by the developer who copied them up. I have not found a way to force ownership to nobody. That doesn't matter, though, since Apache does not use owner permissions and web developers get permissions through the group settings. If you are picky about this, it is easy to set a cron job that runs chown on a regular basis.
On Fri, 2017-07-07 at 12:31 +0100, John Hodrien wrote:
Not necessarily. In order to change permissions on a file you need to have write access to the directory (i.e. the special file in the parent directory that describes the files present in the directory). The owner of a file does not necessarily have those permissions in a normal directory.
P.
On Fri, 7 Jul 2017, Pete Biggs wrote:
To delete, yes, but to chmod? It makes no sense for that to be the case, as hardlinks would end up being a touch baffling.
[ as root ] # mkdir foo # touch foo/bar # chown user foo/bar # chmod 574 foo/bar
[ as user ] $ cd foo $ ls -ld . drwxr-xr-x. 2 root root 16 Jul 7 12:51 . $ ls -l bar -r-xrwxr--. 1 user root 0 Jul 7 12:51 bar $ echo rabbits > bar bash: bar: Permission denied $ chmod 644 bar $ echo rabbits > bar $ cat bar rabbits $ ls -l bar -rw-r--r--. 1 user root 8 Jul 7 12:54 bar
jh
On Fri, 2017-07-07 at 12:56 +0100, John Hodrien wrote:
Yes, you're right. Sorry. The permissions must be held in a different place (chmod isn't suid so it can't write to the directory file if it doesn't have the correct permissions) - it's a long time since I last looked at filesystem internals.
And this has drifted too far away from apache!
P.
-
Bill Gee -
John Hodrien -
Nicolas Kovacs -
Pete Biggs