Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.....
Click here to see the post LQ members have rated as the most helpful post in this thread.
This seems like it would be exceedingly dangerous. By making the files owned by root, an intruder would need to gain root privilege in order to modify the content.
Would you please explain what I am missing?
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.
@druuna, would you please clarify something that I am conceptually missing from your advice. If I read your post correctly, you are advocating making the web files owned by the Apache process. My understanding is that should Apache become compromised by an intruder, that these files by being owned by this process would be modifiable by whomever took control of the process. From my recollection, setting a false login shell does not prevent this as many processes have been locked out of login, but update (write) to files. This seems like it would be exceedingly dangerous. By making the files owned by root, an intruder would need to gain root privilege in order to modify the content.
Would you please explain what I am missing?
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.
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....
Quote:
chown -R apache:apache /srv/www: By default, the installation process installs files (documentation, error messages, default icons, etc.) with the ownership of the user that extracted the files from the tar file. If you want to change the ownership to another user, you should do so at this point. The only requirement is that the document directories need to be accessible by the httpd process with (r-x) permissions and files need to be readable (r--) by the apache user.
FYI - BLFS covers this by saying that part of the command is optional.
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).
If all the files in /vaw/ww/html (eg index.php) have root ownership, doesn't that allow a hacker to run web hacks through root?
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.)
Quote:
Originally Posted by druuna
/var/www and all it files/subdirectories should be owned by the user and group that runs apache (apache:apache for example)!!
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
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:
Code:
mv -f filefile.saved && cp file.saved file
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.
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?
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.
where you can use any name for the webstuff group, as long as it does not yet exist. Then, add
Code:
umask 0002
into your shell startup file; for example .bashrc if you use bash. Then restart Apache and you're pretty safe.
Quote:
Originally Posted by qwertyjjj
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?
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.
Quote:
Originally Posted by qwertyjjj
Presumably the webmaster code above is how shared hosting cxompanies run their servers?
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?!
If I unpack this in the /var/www folder, which has root permissions, doesn't this give the malicious code root permissions as well?
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.
Quote:
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?!
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.
Last edited by Noway2; 04-07-2011 at 04:36 AM.
Reason: typo
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?
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.
Quote:
Originally Posted by qwertyjjj
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?!
Correct. You have a number of ways you can make this work:
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.)
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.