Hi,

The false login is just there to make sure that nobody can login directly as this user and get a valid shell.

Too my knowledge (it has been a while) when setting root as owner/group for the htdocs dir and its subdirs / files, you could create a possibility that a normal user can create executable files and a possibility for a root compromise. This does depend on the permissions that are set, I know.

I have to admit that what you are writing sounds plausible/correct, and I've been looking for proof either way and cannot seem to find it (both methods are mentioned, no definite answer).

Maybe one of the security specialist here can shed some more light on this issue (you made me doubt myself.... Not necessarily a bad thing, I need to keep thinking, but definitely disturbing in this case).

PS: If you are correct, the BLFS documentation includes one hell of a security issue for apache.....

You aren't missing a beat!

Should someone be able to execute code as the apache process, your entire /var/www/* directories are accessible. This means, for instance, someone could put malware into your site and compromise all of your users, persistently. If they have access to execute code as your web-server, though, remember that they can always poison fread() and fwrite() commands in that process context and serve whatever they want. It won't survive a process restart, though.

Currently, I create a separate (locked) user and group for each of my sites - in order to make modifications you'll need to run as that user (accessible via a locked down sudo config).

PHP is served via a backend process running as nobody:nogroup with a locked down php.ini (disallowing things like dl operations,exec operations,socket operations, etc.).

My web-server runs as www-data:www-data

The idea is layering your security. Technically, I see nothing wrong with setting everything root:root, except that you then must give out more ways of legitimate users who need to modify static content to gain access to root:root.

Yeah, I'm having this same problem.

The web server should be running as a web admin account (best practice is to NOT take the default apache:apache, though). If someone gains access to the system through the web server, then they'll be fenced in by the permissions granted to that userid, and the damage they can do limited strictly to what the web admin account has access to.

Making that account the owner of more directories gives the attacker more things it can damage, effectively making the system LESS secure.

To the OP: As long as your Apache server is not running as root, an attacker cannot gain root access through an attack on Apache. He'd have to find another vulnerability to pick up root access from within the Apache userid's purview. The less privileges the Apache userid has on the system, the less the attacker can do, and the more difficult you make it for him to root the box.

Hi,

I just found some proof in one of my apache books.

You (Noway2) are correct, although using root:root is, in none-home-use, wrong

You're remark about the dirs/files being owned by the user/group that runs apache is correct! Giving all to root:root is wrong (webdevelopers and/or webmasters need to have root access in this case to add/edit/remove files, which is not what you want).

I just noticed orgcandman reply, which basically says the same thing.

@qwertyjjj: If you are running this apache machine at home and thus have unlimited access you should restore what you changed
Guess I also need to drop the BLFS maintainers a message about this....

FYI - BLFS covers this by saying that part of the command is optional.

The way the BLFS document is set up, the chown -v -R apache:apache /srv/www command is part of a major block and still part of the make install process block. Normally if something is optional BLFS mentions this in a separate block, which will give the builder a choice.

I do wonder if they meant that the command is optional: the installation process installs files with the ownership of the user that extracted the files from the tar file. This extracting is done my a normal user, you do not want your /srv/www to be owned by a normal everyday user.

It would be better in my opinion to move the chown command and remarks about it to its own block and thus reduce the chance of a mistake (or at least force the builder to take more notice).

A more elaborate explanation on the side of BLFS on this subject would also be wanted (in my opinion).

No, absolutely not. The file ownership is an indicator -- which user and which group can do things to the file --, it does not grant anyone accessing the file any special rights. (There are set-user-id and set-group-id bits, that show up as s in the directory listing, but you should not use them with files served by Apache at all; they're intended for special application binaries. For directories, the bits do something totally different.)

NO! ABSOLUTELY NOT!

If you do that, you allow Apache and any scripts it runs, to modify existing files and to create new ones. Any slight programming bug in any of your scripts, or a slight error in Apache configuration (allowing anonymous DAV, for example) will expose your Apache server for malicious use.

If you run a known Apache server, you'll see in the logs that there are people out there that scan servers for known script vulnerabilities. If you happen to have one of those in your server, and you're using the configuration Druuna suggested, your server will be subverted. At minimum, it will be used as a drop-box for illicit files, or for spreading malware or viruses; at worst, they'll upload a script that uses an unpatched security vulnerability to get full control of your server. At that point, you're screwed: only a full reinstall from known good sources will give you back the control of your server.
_ _ _ _ _ _

A much better scheme is to create one or more local groups for web content control, and let the users modify the content as themselves.

The idea is that you set the set-group-id bit for all directories (but not for any files). This has the effect that any new file or directory created in that directory will inherit the group owner from the directory, not the user. (All subdirectories created in that directory will automatically inherit the bit, too.)

Each user that is allowed to modify some web content is given membership to that group. All users will need to set their umask to 0002, so that the files and directories they create grant the group read and write access.

Here's how you do this:

• Create group webmaster.
  Add all users that are allowed to modify web pages to this group.
  
• Make sure webmaster users set their umask to 0002.
  The easiest is to modify /etc/bashrc or /etc/profile, depending on the distribution. I personally add
  
  Code:

  groups=" `ìd -Gn` "
  [ "${groups// webmaster /}" != "$groups" ] && umask 0002
  unset groups

  after the existing umask setting; this will set umask to 0002 for all users that belong to the webmaster group.
• Make sure all web directories and files have the correct access mode:
  
  Code:

  sudo find /var/www/html -type d -depth -exec chown root:webmaster '{}' ';'
  sudo find /var/www/html -type d -depth -exec chmod u=rwx,g=rwxs,o-w '{}' ';'
  sudo find /var/www/html -type f -exec chgrp webmaster '{}' ';'
  sudo find /var/www/html -type f -exec chmod u=rw,g=rws,o-w '{}' ';'

Here's an example of how that looks in practice:
Since Apache is not a member of the webmaster group, Apache and any scripts it runs cannot modify any files or upload new ones. (You can use SUExec to run some scripts as a specific user account if they need the ability to modify web-published files.)
Each webmaster user can modify any files owned by the group. The owner of the file indicates which user created the file. (A webmaster user can prohibit others from modifying a specific file via command chmod g-r file, but that should be reserved for exceptional files.)

To "own" a file, a webmaster user can simply copy it:
If you are a larger organization, you simply create multiple different local webmaster groups. After all, any user can belong to multiple groups.

If you wish to restrict the access to the web directories, create another local group, for example webcontent. Assign all webmaster users also to this group. Also add Apache to this group. Finally, change the ownership and mode of the /var/www directory only:
Now only those users and Apache can access any of the web directories under /var/www/. Note that the webcontent group does not have any write access, only read and traverse rights, thorough the /var/www directory; no others have any access rights. This acts like a bottleneck, keeping any user not belonging to the webcontent group out of the entire web tree.

Hope this helps.

5 members found this post helpful.

Wow, looks like a learned a little bit more about apache today. Thanks guys for that.... And what a thread this turned into.....

Now I'm lost. This is my own server so do I just change everything back to root:root?
I still don;t understand how that is secure, if a use gains access then they can change all files marked as root can't they? ...especially if safe mode is off.
Presumably the webmaster code above is how shared hosting cxompanies run their servers?

If a user gains access, what they'll gain access to is the Apache daemon, which will give them the ability to execute commands as the Apache daemon's userid. So if you run Apache as root, they'd have root access.

This is why you run Apache as a non-privileged account, created solely for the purpose of running Apache and nothing else. Give this account the minimum permissions it needs in order to run, and that'll limit the damage any remote attacker can do to your system if they should hack you through a vulnerability in the web server.

If you give your Apache userid full ownership of those files and directories, that means an attacker can change your entire application environment, and you might find yourself hosting someone else's malware site, for example. That userid only needs read access for most of that material, so you give file ownership to a user with higher privileges (root would work, though you could also make it your personal userid if you want), and make the files world-readable. Now the same hacker can look at the setup of your Apache server, but they can't change any of the configurations or content.

1 members found this post helpful.

It's up to you, but if you want to follow my recommendations run
where you can use any name for the webstuff group, as long as it does not yet exist. Then, add
into your shell startup file; for example .bashrc if you use bash. Then restart Apache and you're pretty safe.

No, of course not. If a user gains access via Apache, they only gain the privileges Apache has. That is usually the apache:apache or www:www user account. (You can see which in your Apache configuration. Check the User and Group directives.)

This means that an attacker that gains access can change all files and directories owned by the apache or www user, and all files and directories that are writable by the apache or www group. This is why you should never change the ownership of the files and directories in /var/www to apache:apache or www:www.

If you mark all files and directories owned by root, you cannot modify them yourself either (other than via sudo).
You could change their ownership to yourself, if you are the only user on that server. That'd be pretty safe, too.

Actually no. Most shared hosting companies only let you have a single user account per web site, so you cannot use this mechanism there.

It is useful when you have multiple maintainers for the same content, and want them to be able to work in parallel. Or, if you have a larger site with maintainership divided into regions, and each maintainer is responsible for content in one or more region. Having the responsibilities overlap means that even if somebody is on sick leave or on a holiday, there is always somebody who can update the content.

Thanks. One more question...
Let's say I download a package of files to be used on a php site but it happens to contain malicious code.
If I unpack this in the /var/www folder, which has root permissions, doesn't this give the malicious code root permissions as well?

Secondly, I now have a php page that is trying to create a file in a folder. It is being refused permissions presumably because the folder is owned by root but running as apache?!

Not necessarily. Linux permissions are such that they are defined independently for owner (root), group, and others. Since the files are owned by root, but run by www-data (or similar) which is neither root or in the root group (hopefully) they will run with the permissions of other. The exception to this is the concept of the setuid bit, which is related to the group id that was described in an earlier response. If this bit it set, then the files will be executed with the permissions of the OWNER not the user's account that is running the process. This point is critical because it is often times used to gain and maintain root level privilege in a compromise and is why it is one of the key things we look for in an investigation of a suspect compromise.

Yes, the permissions would prevent this. Typically this is what you want. You don't want apache users, i.e. the public, to be able to write stuff to your web document space, or any other space on your drive. If you have a PHP application that needs to use files for temporary storage, you can use the /tmp directory which has very loose permissions, typically 777.

No. The malicious code will only be able to modify files owned by the apache user.

If you install a CMS or other package which installs additional Apache configuration in /etc, you should check if it uses for example SUPHP or SUExec to run scripts under another user account.

Correct. You have a number of ways you can make this work:

1. You can allow Apache (or everybody) to write to that folder.
   There is a slight risk in this option, but if the modified files must be publicly accessible, this is often acceptable.
   (When using web hosting services, this is sometimes the only supported option.)
2. You can modify the PHP script so that it creates the files outside the WWW tree, for example in /var/www/script-data/, and allow Apache to modify and create files in that directory.
   
   Code:

   sudo mkdir /var/www/script-data/
   sudo chown root:apache /var/www/script-data/
   sudo chmod 02775 /var/www/script-data/

   Since this directory is outside the normal WWW tree, it is less likely exploitable by accidental security holes in scripts and Apache configuration.
   I recommend this if you use a web hosting service which only provides a single user account for you, but allows you to modify Apache configuration.
3. You can set up a separate user account, and run that PHP script via the SUExec mechanism.
   This is the most secure option, but requires a bit of Apache configuration. Most web hosting services only give you a single user account per site, so this option is usually only available if you have your own physical or virtual server.
   In most cases you'll also want to use mod_rewrite to map the web-visible URLs to ones better suited for SUEXECing.

Well, this thread is really very, very good. I was looking for these answers long time too.

How can help .htacces here to us? Is it a different way of solving this access limitations (permissions) issue on web files and directories?
What can be a drawback of specifying access rights with this instead of the other way?

I think this can be useful since lots of php applications provides their code with pre-configured .htaccess files. Specifying the exact access as it should be in each directory.