LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
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-07-2005, 12:05 PM   #1
frgtn
LQ Newbie
 
Registered: Mar 2005
Location: Kaunas, Lithuania
Distribution: Slackware 10.1
Posts: 28

Rep: Reputation: 15
Multi-user web server problem


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?
 
Old 04-07-2005, 01:21 PM   #2
tangle
Senior Member
 
Registered: Apr 2002
Location: Smithville, TN
Distribution: Slackware
Posts: 1,745

Rep: Reputation: 71
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.
 
Old 04-07-2005, 02:03 PM   #3
frgtn
LQ Newbie
 
Registered: Mar 2005
Location: Kaunas, Lithuania
Distribution: Slackware 10.1
Posts: 28

Original Poster
Rep: Reputation: 15
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? )
 
Old 04-07-2005, 02:17 PM   #4
tangle
Senior Member
 
Registered: Apr 2002
Location: Smithville, TN
Distribution: Slackware
Posts: 1,745

Rep: Reputation: 71
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.
 
Old 04-07-2005, 02:22 PM   #5
frgtn
LQ Newbie
 
Registered: Mar 2005
Location: Kaunas, Lithuania
Distribution: Slackware 10.1
Posts: 28

Original Poster
Rep: Reputation: 15
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.
 
Old 04-08-2005, 03:47 AM   #6
TigerOC
Senior Member
 
Registered: Jan 2003
Location: Devon, UK
Distribution: Debian Etc/kernel 2.6.18-4K7
Posts: 2,380

Rep: Reputation: 49
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.
 
Old 04-08-2005, 03:17 PM   #7
sigsegv
Senior Member
 
Registered: Nov 2004
Location: Third rock from the Sun
Distribution: NetBSD-2, FreeBSD-5.4, OpenBSD-3.[67], RHEL[34], OSX 10.4.1
Posts: 1,197

Rep: Reputation: 46
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

Last edited by sigsegv; 04-08-2005 at 03:30 PM.
 
Old 04-08-2005, 04:10 PM   #8
TigerOC
Senior Member
 
Registered: Jan 2003
Location: Devon, UK
Distribution: Debian Etc/kernel 2.6.18-4K7
Posts: 2,380

Rep: Reputation: 49
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");
?>
 
Old 04-08-2005, 05:01 PM   #9
sigsegv
Senior Member
 
Registered: Nov 2004
Location: Third rock from the Sun
Distribution: NetBSD-2, FreeBSD-5.4, OpenBSD-3.[67], RHEL[34], OSX 10.4.1
Posts: 1,197

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

Last edited by sigsegv; 04-08-2005 at 05:28 PM.
 
Old 04-09-2005, 01:57 AM   #10
TigerOC
Senior Member
 
Registered: Jan 2003
Location: Devon, UK
Distribution: Debian Etc/kernel 2.6.18-4K7
Posts: 2,380

Rep: Reputation: 49
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.
 
Old 04-09-2005, 02:24 AM   #11
sigsegv
Senior Member
 
Registered: Nov 2004
Location: Third rock from the Sun
Distribution: NetBSD-2, FreeBSD-5.4, OpenBSD-3.[67], RHEL[34], OSX 10.4.1
Posts: 1,197

Rep: Reputation: 46
>> 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

Last edited by sigsegv; 04-09-2005 at 02:30 AM.
 
Old 04-09-2005, 02:33 AM   #12
TigerOC
Senior Member
 
Registered: Jan 2003
Location: Devon, UK
Distribution: Debian Etc/kernel 2.6.18-4K7
Posts: 2,380

Rep: Reputation: 49
Your arrogance is unbelievable - I'll go somewhere else to find out what I need to know - thank you.
 
Old 04-09-2005, 02:50 AM   #13
sigsegv
Senior Member
 
Registered: Nov 2004
Location: Third rock from the Sun
Distribution: NetBSD-2, FreeBSD-5.4, OpenBSD-3.[67], RHEL[34], OSX 10.4.1
Posts: 1,197

Rep: Reputation: 46
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.
 
Old 04-09-2005, 08:56 AM   #14
SteveK1979
Member
 
Registered: Feb 2004
Location: UK
Distribution: RHEL5/6, Solaris 10/11, NetBSD, OpenBSD, FreeBSD, MacOS
Posts: 221

Rep: Reputation: 40
Thumbs up

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
 
Old 04-13-2005, 09:01 AM   #15
frgtn
LQ Newbie
 
Registered: Mar 2005
Location: Kaunas, Lithuania
Distribution: Slackware 10.1
Posts: 28

Original Poster
Rep: Reputation: 15
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).
 
  


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
Permission problem with uni multi-user webserver Proud Linux - Security 5 04-17-2005 11:42 AM
Why can't a Linux web server have only one user? veeruk101 Linux - Newbie 4 03-31-2005 03:03 AM
Web Server to able to Access by Authorise User. Kitara Red Hat 0 06-04-2004 01:52 PM
MS Access DB File multi User problem with SAMBA hellertech Linux - Networking 0 07-14-2003 05:51 PM
server set up, multi user tevtango Linux - General 0 02-27-2002 11:12 PM


All times are GMT -5. The time now is 05:59 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