Multi-user web server problem

frgtn · 04-07-2005, 12:05 PM

Hi
I'm very tired from last night's log analysis, so sorry for my bad english. So here's the reason i'm writing:
There's a web-server in my school with multiple users, each got their web-stuff in public_html. There's also access through ssh. The problem is that for apache to be able to read your web-files you need to give permission "r" for everyone. This way other users can also then view and download your php scripts which are in public_html. I didn't care much about it until yesterday, when a malicious user started poking around other users files through his shell. Result - the site of my class got stolen and it's database was partly deleted ( 15 megs of statistics ). Is there any way to prevent other users from accessing my files and in the same time allowing apache access?

tangle · 04-07-2005, 01:21 PM

If your permissions where set to read only, he should not of been able to delete files and the database. Sound to me like either your permissions where set to other than read only or he cracked your system.

frgtn · 04-07-2005, 02:03 PM

well no, he didn't crack the system. The point is that since apache needs to read ~/public_html, the permissions were set to 644. he has read mysql login from web engine config and truncated what he thought were logs.
P.S. apache runs on an unprivilleged user, so this permission stuff is necesery ( or maybe not? )

tangle · 04-07-2005, 02:17 PM

I understand that, the file that are to be serverd to the public need to have read access to the world and that apache run as nobody (or apache). If your file permissions are set to 644 and he is not in the owner, he can not write to it or delete it without doing something malious.

But, I still do not understand how he can delete a file, it he only have read access.

frgtn · 04-07-2005, 02:22 PM

he didn't delete anything. he just obtained database login info from web-engine and messed up the database. Now i'm trying to figure out how to prevent simple users from reading the files and allowing only apache to have access.

TigerOC · 04-08-2005, 03:47 AM

I have been pondering the security of the php query method since I saw the structure and actually posted my thoughts earlier before reading this thread which confirmed my suspicions.

Have a look at the thread I posted to http://www.linuxquestions.org/questi...hreadid=310975 and I think the answer lies in defining a user who only has read rights and defining this as the user in the php query. If someone gains access via the details to the database by other means then they only have read rights and unable to damage the database.

sigsegv · 04-08-2005, 03:17 PM

Oh come on guys ... this is an easy one

Code:

chown -R <userid>:<apache's group> /home/user/public_html
find /home/user/public_html -type f | xargs chmod 640
find /home/user/public_html -type d | xargs chmod 750

or, as a script suitable for running from cron:

Code:

#!/bin/sh

# WARNING! This assumes your apache's group is 'www'

cd /home

for USER in *; do
    if [ -d $USER ]; then
        if [ -d $USER/public_html ]; then
            echo "Forcing permissions on $USER/public_html"
            # Change the next line if Apache's group isn't www
            chown -R $USER:www $USER/public_html
            find $USER/public_html -type f | xargs chmod 640 
            find $USER/public_html -type d | xargs chmod 750
        fi
    fi
done

This gives Apache r-x on directories (which is all it should need) and r-- on files. The user that owns the files gets rwx on directories and rw- on files. Everyone else gets nothing

Obviously, if you have CGI scripts/programs under their public_html directories you'll have to adjust accordingly.

HTH

Edit: As an additional thought -- filesystem permissions are not a substitute for proper user administration and use inside the database itself. Security in layers and all that

TigerOC · 04-08-2005, 04:10 PM

I don't think you got the point of this one. Its not a question of ownership of the files in the public directory but the fact that the user and password are defined in the php script that queries the database. Since you have that information it can be used to access the database. Like I said defining the user rights on access to the database is the important point.

Here is a sample of the code that I am talking about. If you view the source of the html page its easy;

<? $hostname = "db1.thinkhost.com"; // The Thinkhost DB server.
$username = "username"; // The username you created for this database.
$password = "password"; // The password you created for the username.
$usertable = "details"; // The name of the table you made.
$dbName = "example"; // This is the name of the database you made.

MYSQL_CONNECT($hostname, $username, $password) OR DIE("DB connection unavailable");
@mysql_select_db( "$dbName") or die( "Unable to select database");
?>

sigsegv · 04-08-2005, 05:01 PM

Quote:

Originally posted by TigerOC
I don't think you got the point of this one. Its not a question of ownership of the files in the public directory but the fact that the user and password are defined in the php script that queries the database. Since you have that information it can be used to access the database. Like I said defining the user rights on access to the database is the important point.

No, I understand the point perfectly well, and it most certainly *IS* a question of ownership of the files! The scripts have to be able to connect to the database or the database isn't a whole lot of good for anything now is it? The fact is, if the permissions on the files are correct, the malicious user doesn't get the login/password in the first place ...

The thing that's potentially wrong about your advice is that you assume the DB user only needs read access. I don't see anything from the OP about that being the case (and if that is the case, shame on the OP for not granting only SELECT on the tables for that user), but I'm guessing that since it's statistics, probably not. If the web app is to do much of anything useful with the data from a manipulation standpoint, the user needs (at a minimum) UPDATE, which will give them the swing to set the DB to all zeros if they get the urge.

As you said (and so did I, BTW), user rights in the DB itself are of course important. Assuming that the whole world only uses databases read only is pretty short sighted though. It's also not addressing the bigger issue. The credentials to the database should have been protected regardless of what access the user has ....

TigerOC · 04-09-2005, 01:57 AM

sigsegv I am sure you are very clever and obviously well versed in Linux and to a much higher level than me. But comments like "Oh come on guys ... this is an easy one" just annoy me. If I understood, I wouldn't ask the question would I? Having got the grievance out of the way lets get to the point.
You need to explain yourself else the information you are trying to put across is useless because I don't understand you and probably the other people as well. We have a miscommunication problem here. So you need to get into some basics so I understand the logic of what you are saying.
I'll try again to explain what I see as the problem.
You have a page that has html code in which is embedded php code to access a particular database and in that php code is the user name and password to connect to the database. Now that page is world readable otherwise it becomes useless. So far we agree. Any browser is capable of showing the source code of the page and divulging the name and password to the that database. So what is stopping me using an application like phpmyadmin to access the database.
Could you explain simply how you either prevent someone viewing the source of the page or getting access to the database. I have several informational databases that I don't want others messing with as they are mine and I want to control what is in there so it must only be readable.

sigsegv · 04-09-2005, 02:24 AM

>> sigsegv I am sure you are very clever

Why thank you. I like to think so.

>> and obviously well versed in Linux and to a much higher level than
>> me. But comments like "Oh come on guys ... this is an easy one"
>> just annoy me. If I understood, I wouldn't ask the question would I?

I had no idea your skin was so thin ... Apologies all around.

>> Having got the grievance out of the way lets get to the point.

Yes let's

>> You need to explain yourself else the information you are trying
>> to put across is useless because I don't understand you and
>> probably the other people as well.

You're making assumptions about the other people in this forum and their level of aptitude to the conversation at hand. Isn't that what I was being chastised for only moments ago?

>> We have a miscommunication problem here. So you need to get
>> into some basics so I understand the logic of what you are saying.
>> I'll try again to explain what I see as the problem.

Mkay ...

>> You have a page that has html code in which is embedded php code to
>> access a particular database and in that php code is the user name and
>> password to connect to the database. Now that page is world readable
>> otherwise it becomes useless. So far we agree.

No we don't.

The PHP code on the server isn't world readable. It should be owned by the user that owns it (duh) and the apache group. If more than one user needs access to the files, then you create a new group and make user1 and user2 members of it, and then apache can own the files with read only access while the users have rw- and rwx. In any case, there should be *no* world readable files that contain username/password info.

The HTML code that the PHP preprocessor spits out isn't world readable. It's generated in memory and then handed to apache to give to the client. The page that the client gets (usually) never exists on disk when discussing PHP.

"World readable" on the Apache server machine's local filesystem means something *completely* different. World readable source files living on the hard drive is what the OP is asking about.

>> Any browser is capable of showing the source code of the page
>> and divulging the name and password to the that database.

No it isn't.

The HTML source that the client browser sees and the PHP source that lives on the server is (again, usually) two totally and completely different things.

>> So what is stopping me using an application like phpmyadmin
>> to access the database.

The fact that you don't have a password, a username, or (most likely) a network path back to tcp/3306 on the MySQL server you want to take over.

>> Could you explain simply how you either prevent someone
>> viewing the source of the page or getting access to the database.

My previous post(s) pretty much already have.

>> I have several informational databases that I don't want others
>> messing with as they are mine and I want to control what is in
>> there so it must only be readable.

If you have multiple users on your systems and they can cat /home/user/public_html/somefile.php, that's bad. See my first post again.

HTH

TigerOC · 04-09-2005, 02:33 AM

Your arrogance is unbelievable - I'll go somewhere else to find out what I need to know - thank you.

sigsegv · 04-09-2005, 02:50 AM

Quote:

Originally posted by TigerOC
Your arrogance is unbelievable - I'll go somewhere else to find out what I need to know - thank you.

You're not the first person to say so (not even the first today)

What exactly do you want to know that I haven't answered? You're right. I do assume that those using LAMP have at least a basic understanding of what each of the pieces do (LAMP being Linux Apache MySQL and PHP). In the simplest terms I can possibly think of:

1) Create *PHP* source file on disk where Apache can find it. Source file has DB credentials in it (along with other junk).
2) Start Apache server.
3) Point browesr to http://you/yourpage.php

4a) The server picks up your request for yourpage.php. The php module in Apache inspects the PHP code in your php file and executes it (think of it like JIT compiling in Java or whatever (even though it's not)). This includes any database calls or whatnot.
4b) Once the script is complete, and assuming there were no errors, the PHP module hands back the complete HTML output of your script to Apache

5) Apache serves you the HTML output and
6) your browser renders it

No where during this process is the source of the PHP (or your DB login/password) exposed to the browser.

Which leads us back to my first post, which was in answer to the OPs question. The OPs problem had nothing to do with any of the stuff discussed in this post. It was all local filesystem permission problems. Another user logged in locally was able to read the source files, get the info for the DB connections and then (presumably) from that same machine (i.e. the webserver), connect to the database that held the information that the site needed and wiped it out or otherwise made it unusable.

SteveK1979 · 04-09-2005, 08:56 AM

TigerOC, even if you think sigsegv is being slightly arrogant here (no comment

), his response looks perfectly correct to me!

Now, has frgtn understood the answer? If not, post back and I'm sure we can go through it again. A web server I look after at work has a similar sort of setup with about 2000 users, and we've only ever had minor incidents over the years (I really shouldn't tempt fate like that, especially as I'm on call this weekend

), no disasters with databases that I'm aware of and it's been there a long time!

Cheers,

Steve

frgtn · 04-13-2005, 09:01 AM

Hey

Thanks for your help, i really apreceate it. The solution for this problem is coming up - admin of the server has promised(!!!) to install suPHP module, so each script can be run on it's owner's rights. I don't know about the permissions and groups, since system() is enabled on the server and users can use php to read each other's files (the ones with 640).