LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 04-06-2011, 09:24 AM   #16
druuna
LQ Veteran
 
Registered: Sep 2003
Posts: 10,532
Blog Entries: 7

Rep: Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371

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.....
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 04-06-2011, 09:48 AM   #17
orgcandman
Member
 
Registered: May 2002
Location: dracut MA
Distribution: Ubuntu; PNE-LE; LFS (no book)
Posts: 594

Rep: Reputation: 102Reputation: 102
Quote:
Originally Posted by Noway2 View Post
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.
 
Old 04-06-2011, 10:10 AM   #18
SL00b
Member
 
Registered: Feb 2011
Location: LA, US
Distribution: SLES
Posts: 375

Rep: Reputation: 111Reputation: 111
Quote:
Originally Posted by Noway2 View Post
@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.
 
Old 04-06-2011, 10:10 AM   #19
druuna
LQ Veteran
 
Registered: Sep 2003
Posts: 10,532
Blog Entries: 7

Rep: Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371
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
Code:
chown -R root:root /var/www
chown -R webalizer:root /var/www/usage
Guess I also need to drop the BLFS maintainers a message about this....
 
Old 04-06-2011, 10:40 AM   #20
orgcandman
Member
 
Registered: May 2002
Location: dracut MA
Distribution: Ubuntu; PNE-LE; LFS (no book)
Posts: 594

Rep: Reputation: 102Reputation: 102
Quote:
Originally Posted by druuna View Post
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.
 
Old 04-06-2011, 11:04 AM   #21
druuna
LQ Veteran
 
Registered: Sep 2003
Posts: 10,532
Blog Entries: 7

Rep: Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371
Quote:
Originally Posted by orgcandman View Post
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).
 
Old 04-06-2011, 11:29 AM   #22
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942
Quote:
Originally Posted by qwertyjjj View Post
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 View Post
/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
    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:
Code:
drwxrwxr-x 8 root root      4096 2011-01-01 12:00 /var/www/
drwxrwsr-x 8 root webmaster 4096 2011-01-01 12:00 /var/www/html/
-rw-rw-r-- 1 user webmaster 2254 2011-01-01 12:00 /var/www/html/index.html
drwxrwsr-x 8 user webmaster 4096 2011-01-01 12:00 /var/www/html/images/
-rw-rw-r-- 1 user webmaster 2254 2011-01-01 12:00 /var/www/html/images/banner.png
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 file file.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:
Code:
sudo chown root:webcontent /var/www
sudo chmod u=rwx,g=rx,o-rwx /var/www
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.
 
4 members found this post helpful.
Old 04-06-2011, 01:09 PM   #23
corp769
Guru
 
Registered: Apr 2005
Posts: 5,807

Rep: Reputation: 996Reputation: 996Reputation: 996Reputation: 996Reputation: 996Reputation: 996Reputation: 996Reputation: 996
Wow, looks like a learned a little bit more about apache today. Thanks guys for that.... And what a thread this turned into.....
 
Old 04-06-2011, 01:26 PM   #24
qwertyjjj
Senior Member
 
Registered: Jul 2009
Location: UK
Distribution: Cent OS5 with Plesk
Posts: 1,007

Original Poster
Rep: Reputation: 30
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?
 
Old 04-06-2011, 01:55 PM   #25
SL00b
Member
 
Registered: Feb 2011
Location: LA, US
Distribution: SLES
Posts: 375

Rep: Reputation: 111Reputation: 111
Quote:
Originally Posted by qwertyjjj View Post
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.
 
Old 04-06-2011, 02:11 PM   #26
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942
Quote:
Originally Posted by qwertyjjj View Post
Now I'm lost. This is my own server so do I just change everything back to root:root?
It's up to you, but if you want to follow my recommendations run
Code:
sudo groupadd -r webstuff
sudo usermod -a -G webstuff your-user-name
sudo chown root:webstuff /var/www
sudo chmod u=rwx,g=rwx,o=rx /var/www
sudo chown root:webstuff /var/www/html
sudo chmod u=rwx,g=rwx,o=rx /var/www/html
sudo find /var/www/html -depth -type d -exec chgrp webstuff -- '{}' ';'
sudo find /var/www/html -depth -type d -exec chmod u=rwx,g=rwxs,o=rx -- '{}' ';'
sudo find /var/www/html -depth -type f -exec chgrp webstuff -- '{}' ';'
sudo find /var/www/html -depth -type f -exec chmod u=rw,g=rw,o-x -- '{}' ';'
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 View Post
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 View Post
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.
 
Old 04-07-2011, 02:15 AM   #27
qwertyjjj
Senior Member
 
Registered: Jul 2009
Location: UK
Distribution: Cent OS5 with Plesk
Posts: 1,007

Original Poster
Rep: Reputation: 30
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?!

Last edited by qwertyjjj; 04-07-2011 at 02:27 AM.
 
Old 04-07-2011, 04:36 AM   #28
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
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
 
Old 04-07-2011, 04:56 AM   #29
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942Reputation: 942
Quote:
Originally Posted by qwertyjjj View Post
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 View Post
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:
  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.
 
Old 04-08-2011, 02:58 PM   #30
hua
Member
 
Registered: Oct 2006
Location: Slovak Republic
Distribution: Slackware 13.37, 14.0
Posts: 391

Rep: Reputation: 49
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.

Last edited by hua; 04-08-2011 at 03:10 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Using /var/www vs. /srv vs. /home/user/public_html NightSky Linux - Server 11 09-06-2010 12:30 AM
Configure /var/www/html for user write access? SlowCoder Linux - Server 9 07-26-2009 05:37 PM
Changing user and group for Apache 2 & /var/www RDReavis Debian 4 04-06-2009 04:32 AM
FTP user writing to /var/www animelook Linux - General 1 08-04-2006 07:38 PM
user/group permissions for /var/www/html/ illtbagu Linux - Software 6 11-12-2003 05:29 AM


All times are GMT -5. The time now is 02:41 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration