Hi,
it seems on the RaQ3 box where I have my site, there is a serious security problem: People with telnet access (actually SSH) can browse through other peoples websites:

What I mean is, if my site is at

home/sites/site29/web

I can simply cd to home/sites/site25 (the site of someone else) and look around.

This way, someone can look into my php files and will find my password for MySql.

What's the usual methode to fix this problem i.e. prevent users on the same box to look into one anothers sites?

I think this is a serious problem. Also I have some graphics work on my password protected site and it would be very bad if someone could steal those graphics especially since I haven't filed the TM for my logo yet.

Any suggestion?

This is a common issue, and one which is hard to get around. Apache can only serve files which it can read, so you have basically three options: First, you could have Apache running as root in order to allow it to read files -- but this is both very scary and a major performance hit due to additional security checks which must be performed. Second, you could add User www into each and every group, and make www files group readable -- except that each user would need their own group, and most systems don't support having a single user (www) in more than about 20 groups.

The third option, of course, is simply to make files world readable, and accept that users can read each other's files.

Oh, and the fourth option is to make all of your private files chmod 600 and access them via suexec'd (or cgiwrapped) scripts. In the case of your PHP this might be practical -- although you'd have to use the standalone PHP interpreter -- but it is rather clumsy (and expensive) to do this for all your files.

And that's the only advantage IIS has over Apache. Simple to configure security and run websites under different usernames.

Originally posted by cperciva
This is a common issue, and one which is hard to get around. Apache can only serve files which it can read, so you have basically three options: First, you could have Apache running as root in order to allow it to read files -- but this is both very scary and a major performance hit due to additional security checks which must be performed. Second, you could add User www into each and every group, and make www files group readable -- except that each user would need their own group, and most systems don't support having a single user (www) in more than about 20 groups.

The third option, of course, is simply to make files world readable, and accept that users can read each other's files.

It might help a little bit if you make your webhosting directories -r+x, ie. can be searched for known filenames, but the directory contents cannot be listed.

I'm not really familiar with apache and httpd configuration, but... What's wrong with making all directories that users serve webpages from g+rs (readable, executable, setgid) and with apache's gid? There must be some practical problem with this or it'd be the defacto process...

Hmm,.. isn't there a way to allow every user to list the content of his own directories, but not the content of others?

I understand that would need a group for every user, because access rights are assigned for groups right?

Why should there be a limit to the number of groups?

I *think* a friend of mine configured bash in such a way to only disallow users from leaving their home directory. I'll see if I can find some info on this and post it here.

Regards,

Mike

Originally posted by astra4
Hmm,.. isn't there a way to allow every user to list the content of his own directories, but not the content of others?


Oh, it is quite easy to stop people ls'ing each other's directories, you just have to clear the world readable flag. The problem is that if they know the file is there they can still read the file.


I understand that would need a group for every user, because access rights are assigned for groups right?


Files have owner, group, and world access rights (in the standard unix model... capabilities-based systems change everything). If a file is chmod 600, it is rw by the owner, but not by anyone else, even someone in exactly the same group(s).


Why should there be a limit to the number of groups?

It's a messy implementation detail dating back to 4.2BSD. Basically there is a limited buffer space in which to store the current user's group list.

Hmm, but from your earlier posting I had understood if files are not world readable there's no practical solution to make Apache serve them?

A really unfortunate thing. On my hosts support forum a thread has been started about this and now users even request that all who want telnet access be put on the same server, so that those who want the feature also take the security risk.

To me this sounds like a lot of administrative work, because sites would need to change server in order to get SSH shell access...

The latest suggestion on our support forum is to use an access control list (ACL). Take sensible files (with passwords or thelike) private and use an ACL to grant access for Apache webserver.

A description of ACL is found here: http://acl.bestbits.at

Seems like not all Linux support ACL though.

Placing everyone with shell access on the same server isn't enough. You'd have to do that for everyone who can read files in any way -- via CGI scripts, SSI, even FTP (unless you chroot it). Basically, that isn't a practical solution.

Using ACLs... well, that's more or less the capabilities I mentioned before, but support for that is limited at best. Although there is code to do this under linux, it is still very new and I certainly wouldn't want to use it on a production system.

Thanks cperciva, interesting comments!

[Damn it, why can't we delete our own posts???]

Actually, there's a very reasonable and simple solution to this, which doesn't require any wrappers or anything really special. Just some basic and very quick changes that will protect user's directories from other's, not just trying to stop them from viewing files and using CGI wrappers, when people have to worry about other's viewing PHP code that is open to viewing unless it's CGI PHP, which takes the point out of PHP, as well as the problem with user's frontpage service.pwd files being able to be viewed and cracked -- assuming they don't grab the actual password from a database connection call (since most user's use the same password to connect to SQL databases that they do for their user account!)

Consider this too, blocking people from viewing files by hiding them from viewing the files in the directories doesn't do much good, since people can guess common paths, compare them to web paths, often view Apache's configuration file (which cn be set to lower permissions), view the log files for the web server (which can be set to lower permissions), use 'ps' to grab the script paths (which can be denied or filtered output), or other means. Those can be stopped easily, but there's far too many means to get simple information like that, especially with no very unique paths, etc. too.

Anyway, there's a few solutions and this is not difficult by any means and only takes a few seconds to minute to implement, without any other installs of any patches, software or anything else, effectively blocking ANY user but Apache and root from viewing or using these files. That right there, should give any semi experienced people a clue of how it's done, but if anyone's interested in how to do this, I'll be happy to tell them in an email. I don't really want to explain to the world of how to do this, yet. Email me and I'll surely let you know, and I might post it here later.

[Damn it, why can't we delete our own posts???]


I wholeheartedly agree :\

Originally posted by Tim_Greer
Anyway, there's a few solutions and this is not difficult by any means and only takes a few seconds to minute to implement, without any other installs of any patches, software or anything else, effectively blocking ANY user but Apache and root from viewing or using these files. That right there, should give any semi experienced people a clue of how it's done, but if anyone's interested in how to do this, I'll be happy to tell them in an email. I don't really want to explain to the world of how to do this, yet. Email me and I'll surely let you know, and I might post it here later.

You DO mean any user but apache, root, and the user himself, right?

Is this solution similar to the one I mentioned above about having public_html files and directories uid user, gid apache (with permissions read, execute and setgid) and no permissions at all for the world?

Nobody's commented about any negative aspects of my suggestion... :(

Yes, those are the user's I had meant (root, Apache and the user themselves, I thought that's what I said?) And, actually that's pretty much about it (with what you said about permissions and Apache's GID and ownership issues), and it's a fairly reasonable solution, possibly in addition to chrooting them (their CGI scripts, PHP, etc.) as well as chrooting their shell access, is to use permissions wisely, not just 711 or 701, etc. but to set permissions on their /home/accountname directory to 750, owned by that user's UID and Apache's GID. Set Apache to run as user "nobody" and the group as "safegrp" or something. Add that group (safegrp) and do:

chmod 711 /home
chmod 750 /home/username
chown username.safegrp /home/username

(no need to set the GID on any other file or directory, other than the main/parent useraccount directory, btw. So don't do that recursively or with any other file or dir.)

Guess what? Now people can't go into other people's directories with a CGI script or shell access, etc. Also, people can't view other accounts frontpage service.pwd files, which is one of the other big problems, and crack them and gain access to many other accounts. Without this sort of implementation, of course, as someone else mentioned, opens people up to having their scripts (CGI (which can be set to 700 and deny them if there's a CGI wrapper) or PHP (which is more difficult, unless it runs as CGI, which takes the point out of it), etc.) and get the clear text password from that file anyway, and not have to crack anything otherwise, since most people use their account password for their MySQL database password.

Guess what else? Now they can't see other user's files. Simply setting the permissions to not list files, is hardly worth the effort, unless you also make paths difficult to guess, which can be cumbersome.

Also, with not allowing people to see files, as we all know, people can still grab or view the files. Also, they can get the paths via ps or viewing the web server's log files, viewing Apache's config files, or other system files, which might or might not have any real value to them, but can possibly be used to find things. And, all of those can be prevented, easily, but it's not a very effective method, although it's one step to a solution and should be done as well

However, with SuEXEC CGI wrapper and the permissions set lower, to allow only the Apache group to access the main account (and therefore, beyond) and set your files past that to 711 for directories and 700 for executable scripts and 400, 600 and 700 for files that are to be read, read and written to, and read, written to and executed, respectfully. And, if you have a file or directory as 777 (who'd do that anyway???), you don't have to worry about other people viewing it, altering it, or uploading to it or deleting it, etc., because they can't get that far down the tree, because they are blocked at the parent directory of the user's main account.

This, will effectively stop people from snooping around and it's very simple and effective. Since Apache runs as nobody (and safegrp, for the GID) and CGI's as the user's UID/GID, no one can write a script to get out of it. I've implemented this and tested it out and didn't fully test it, but it did work very well and it makes sense and is all very easy to do. Implementing a wrapper and filters is a good step too, as well as denying or filtering output from certain tools like ps, etc. and denying people from viewing the log files of others, per account or globally. This will stop a lot of people from getting much information.

Even if user's run CGI scripts without a wrapper, which I think should be enforced by default on web servers (they can run under the web server's UID and not GID), as well as some protective (these very basic, to start at least) measures to prevent problems. It can be helpful to set the web server's configuration file to not be viewable by the users, as well as other such files that reveal paths, etc. Put your user's home directory on a partition that's mounted as denying SUID and SGID scripts, set permissions to disallow user's from viewing information or using services on the system to get paths, usernames, environmental variables and paths and commands/values. Lot's of simple things like this, to start, where it keeps the majority of trivial file system snoopers clueless and makes them think twice about trying things or going further. it's only a two minute job, if that, to do and it improves the system integrity enough to at least stop wanna-be idiot's from getting access and passwords and information, etc. of other user's accounts.

That should be a basic and standard thing that few web hosts bother with and leads up to gathering more and more information which can result in being rooted, if you are careless or aren't concerned about these basic things. So, it's good to see people aware of them and wanting to know how to stop them, since I've seen far too many self-proclaimed stable, quality and secure (and experienced) hosts (which they obviously are not), not know how or care to try and prevent these things. Already, just wanting to know how to prevent it, shows you're more advanced than the larger hosts or the people that like to claim things. I mean, the fact that A: You notice this, means you know something they don't, and B: The fact you want to find a solution to it and see the potential for concern for user's privacy and information and how it can protect your system better, even if a small issue, shows the same, as well as better service. So, Kudo's to that! :-)

There's certainly more, but for this subject, that will work pretty well. I personally would likely find my own solution, instead of using tools to protect it, unless it's a good wrapper or something, because tools are often exploited and make things worse. Anyway, nothing secret or difficult, but I just didn't want to try and explain it and confuse people... But, I think it's best. Anyway, that's the basics of it and basically all someone needs to do, or to work off of.


PS: Pyng, What were the negatives aspects of your post and how, if at all, are they relevant to mine? This gets around the possible problems, but I haven't tried to circumvent this solution either -- although it's the best I can explain it at 4:15 AM with no sleep.

[Edited by Tim_Greer on 04-04-2001 at 07:56 AM]

Tim's solution is unquestionably devious, and manipulates the quirk in *some* file systems (in fact, I think most commonly used file systems) which allows the owning user of a file to not be a member of the owning group.

It should be pointed out, however, that this solution has the disadvantage of monopolizing the group flags -- it becomes impossible to have files shared by two different users. This could well be considered a significant problem, as most security-conscious users would probably want to have a separate account for running (possibly insecure) cgi scripts from. (ie, have a "user" account and a "usercgi" account, both of which are in group "user").

I'm in the process of setting up a server for a new hosting company. Here's what I've come up with so far to deal with the problem:

I keep all the site files in /home/apache and each user has a symbolic link from their home directory to their site. Apache is running as "apache". The permissions are set up as follows:

/home/apache has the following:
drwxr-x--- 17 karaoke apache 4096 Apr 1 20:52 karaoke

/home has:
drwx------ 5 karaoke karaoke 4096 Apr 1 20:49 karaoke

And karaoke's home directory has a symbolic link to the actual site directory:

lrwxrwxrwx 1 karaoke karaoke 19 Apr 4 11:45 public_html -> /home/apache/karaoke/

In my apache config, the site's directory is set as /home/apache/karaoke

This seems to prevent other users from looking at karaoke's files, while allowing apache access to it. Though I guess you still cannot let a group have access to the files...

Does anyone see any reason this wouldn't work? I've got a month before we go live, so I've got some time to work on it some more if necessary...

Ron

Originally posted by cperciva
Tim's solution is unquestionably devious, and manipulates the quirk in *some* file systems (in fact, I think most commonly used file systems) which allows the owning user of a file to not be a member of the owning group.

It should be pointed out, however, that this solution has the disadvantage of monopolizing the group flags -- it becomes impossible to have files shared by two different users. This could well be considered a significant problem, as most security-conscious users would probably want to have a separate account for running (possibly insecure) cgi scripts from. (ie, have a "user" account and a "usercgi" account, both of which are in group "user").

Yes, that does give the problem for group sharing. However, those people, as you said, if they were concerned about security, would have their own accounts. A modification to that solution would be in order at that point... I think I could find a solution... let me think about this (I don't see this as being a problem for most servers or that many user's sharing accounts, but surely, that can pose a problem).

How about special directories in one or the other user's account and having the main account owner and group normal and then just changing the group of web and cgi-bin (of they aren't already in the web root path) directories, and putting symbolic links to the files from the other person's web root, if they are to be accessed via the web? That will fix the problem and they can be selective about what files they share, which those user's can share a private group only. CGI files can likely still be shared and run as the Apache user, because SuEXEC can be disabled (since it'd error otherwise anyway, because the UID/GID wouldn't match) for that specific directory and not screw up with symbolic links, if they use SuEXEC at all anyway, or any other wrapper.

Therefore, even though I wouldn't suggest sharing anything important, they can. However, my opinion would be, that these people can share the same parent account and share their files within that account path, for their account home directories and files, etc. That would ensure that only those two user's could access each other's files. I'm sure there are other solutions, but those would seem to be reasonable, especially if you just customize if for the users in question and you can still chroot (FTP, at least and shell, etc. too) them into their own directory so they can still keep files private from each other, if they wanted to.

Also, I should point out, it was a solution, originally, to ensure that people could deny other user's access to their account and files, etc. This is also easily a case-by-case basis. You don't have to commit to my original implementation on any accounts you don't wish to. So, for special cases, without going any further into the problem, you simply don't change their main account's group and use other solutions, where they can share groups. Also, they really can still do that anyway, by being in the same group, for that user they need to access the files of. Again, simply, don't implement it and use another viable solution, which shouldn't be too difficult to come up with, in place of the one I suggested. It temps me to write a system-wide wrapper and just get away from any problems like this anyway.

Originally posted by Tim_Greer
PS: Pyng, What were the negatives aspects of your post and how, if at all, are they relevant to mine? This gets around the possible problems, but I haven't tried to circumvent this solution either -- although it's the best I can explain it at 4:15 AM with no sleep.


Nothing. At the time I posted, you hadn't given any details of your suggestion, and nobody had commented about my suggestion. I was asking if anybody saw loopholes/bad points in my suggestion...

Setting the user's $HOME directory to 750 will take care of most things. It could potentially be circumvented if someone manages to create hard links to the user's files, and /home isn't on a partition of it's own :) But this scenario borders on the ridiculous.

So, both Tim's and compsci's ideas seem to hold merit.

Originally posted by pyng
Originally posted by Tim_Greer
PS: Pyng, What were the negatives aspects of your post and how, if at all, are they relevant to mine? This gets around the possible problems, but I haven't tried to circumvent this solution either -- although it's the best I can explain it at 4:15 AM with no sleep.


Nothing. At the time I posted, you hadn't given any details of your suggestion, and nobody had commented about my suggestion. I was asking if anybody saw loopholes/bad points in my suggestion...

Setting the user's $HOME directory to 750 will take care of most things. It could potentially be circumvented if someone manages to create hard links to the user's files, and /home isn't on a partition of it's own :) But this scenario borders on the ridiculous.

So, both Tim's and compsci's ideas seem to hold merit.

I see, and yeah, I agree. And, /home ought to be on a different partition anyway, for many security reasons. If you can think of anyway around that, without going into exploits or something, let me know and I'll rethink my plan.

Thanks all, I just learnt that security doesn't just happen ;)

Originally posted by astra4
Thanks all, I just learnt that security doesn't just happen ;)

uh... wait, it's not!? Oh, crap!.. Well, I better find a new job... *l*

You know what I will do when I'll make my first site with member area, where security matters? (ok, for the first one it's almost too late, I already did it in PHP.. so for the second?)

I'll use JSP/Servlet!

The java environment seems to take care of all the security stuff, I just read an article about this JSP/Servlet stuff and the general recommendation was: Don't try to implement any security yourself, just use the mechanisms provided by the Java environment.

I like that. Once everybody uses Java, there's no more need for security gurus, but you can still become a Java guru, Tim ;)

Originally posted by astra4
You know what I will do when I'll make my first site with member area, where security matters? (ok, for the first one it's almost too late, I already did it in PHP.. so for the second?)

I'll use JSP/Servlet!

The java environment seems to take care of all the security stuff, I just read an article about this JSP/Servlet stuff and the general recommendation was: Don't try to implement any security yourself, just use the mechanisms provided by the Java environment.

I like that. Once everybody uses Java, there's no more need for security gurus, but you can still become a Java guru, Tim ;)

*l*.. I'm not a big fan of Java, but Java is more secure than a lot of other language interfaces, but it still isn't completely secure -- although it's built to be more secure, definitely (in the design itself). I'm not worried about a language taking away my job, even though security is only part of my job, since much of this still comes down to how the system is set up, configured, tweaked, etc.

Unless people want to all get together, come up with a means to secure a system's services and shut off everything but web access and only allow people to use a Java interface. That would surly make it very secure, but not very enticing for a lot of people that want hosting. So, I'm fairly certain my future is 'secure' (sorry, couldn't help it), since there's so much more to it than that... :-)

This will be easier for operating system with ACL support,
however it still be possible with o/s without ACL such as
Linux.

First you should configure Apache to use suexec wrapper,
this way cgi scripts will run as the owner of the script,
not the httpd user. You also should not serve content by
using httpd module because it will be running as the httpd
user, and it will be impossible to secure your users' home
directory. I heard Apache 2.0 will be able to serve content
with module using different userid for different sites, but
Apache 2.0 is still far from stable.

Next step, I configure each home directory with mode 750,
and owned by group www (www is my httpd groupid). This way,
another user will not be able to peek into my homedir.
But httpd will be able to serve my files because of the
group permission. The drawback is, users will be able to
change their homedir group ownership, but will not be able
to change it back to 'www' because they don't belong to
group 'www'.

Originally posted by priyadi
This will be easier for operating system with ACL support,
however it still be possible with o/s without ACL such as
Linux.

First you should configure Apache to use suexec wrapper,
this way cgi scripts will run as the owner of the script,
not the httpd user. You also should not serve content by
using httpd module because it will be running as the httpd
user, and it will be impossible to secure your users' home
directory. I heard Apache 2.0 will be able to serve content
with module using different userid for different sites, but
Apache 2.0 is still far from stable.

Next step, I configure each home directory with mode 750,
and owned by group www (www is my httpd groupid). This way,
another user will not be able to peek into my homedir.
But httpd will be able to serve my files because of the
group permission. The drawback is, users will be able to
change their homedir group ownership, but will not be able
to change it back to 'www' because they don't belong to
group 'www'.

You covered a small portion of what we've already dicussed in this very thread already. As for user's changing that, they can be advised not to, which if they do, it's their problem. However, there can be ways to stop them, but why bother if they are going to purposely change the ownership pf the group?

Originally posted by astra4
Hi,
it seems on the RaQ3 box where I have my site, there is a serious security problem: People with telnet access (actually SSH) can browse through other peoples websites:

What I mean is, if my site is at

home/sites/site29/web

I can simply cd to home/sites/site25 (the site of someone else) and look around.

This way, someone can look into my php files and will find my password for MySql.

What's the usual methode to fix this problem i.e. prevent users on the same box to look into one anothers sites?

I think this is a serious problem. Also I have some graphics work on my password protected site and it would be very bad if someone could steal those graphics especially since I haven't filed the TM for my logo yet.

Any suggestion?

To avoid problems with shared servers and readable PHP files containing MySQL passwords, here’s a simple solution.

1. Login as root with telnet or SSH
2. Go to the main “web” directory (public html folder) of the virtual site you wish to add protected php files for
3. mkdir php
4. cd php
5. mkdir protected
6. chown ***username*** protected
7. cd ..
8. chmod 710 php
9. chown ***username*** php
10. chgrp httpd php

Replace the above ***username*** with the site admin’s username and you’ll get:

/home/sites/site#/web:
drwx--x--- 3 ***username*** httpd 1024 May 16 13:50 php

/home/sites/site#/web/php:
drwxr-sr-x 2 ***username*** site# 1024 May 16 13:55 protected

/home/sites/site#/web/php/protected:
-rw-r--r-- 1 ***username*** site# 675 May 16 13:52 php_file.php

What the above steps will do is create a secure directory for php files:
EX: http://www.domain.com/php/protected/php_file.php

No other users on the shared server will be able to access the php files except through the their browser at which point they won’t see any actual php code containing passwords anyway. :D

How does this address the problem where I can use PHP from my virtual server account to include your PHP files by their file path (/home/yourusername/www/file.cfg) and consequently read your mySQL username and password from your config variables?

If you don't somehow block Apache from being able to read files outside the home directory of the web user space, you are still screwed.

I'm not using telnet to read your files, I'm using the web server, which still has access.

-t

Well, you simply solve those type of problems by using a real script alias for CGI scripts (so nothing can be viewed without it trying to execute -- and therefore work or error), or with PHP and other file extensions such as that, just name any included file with that same file extension (i.e., config.php, instead of config.inc) so nothing it seen as clear text, etc., unless you tell it to. Also, configure the web server to not allow directory listings anyway -- even if it's not needed at that point and don't name file names obvious and easy to find. It might be annoying to rename some of the included files to .php, but it will protect the web end of it and it's not that much trouble. That should solve the problem all around in regards to the issue discussed, even if they aren't completely fool proof with al lthe compromises and exploits and other system configuration problems people suffer from.

Sorry Tim, you weren't paying attenting.

The file is called config.php. I'm not reading it in from the web client, I'm including it from a PHP script like this:


<?php
require("/path_to_file/config.php");
echo "<html><body>";
echo "<p>var1: $var1";
echo "<p>var2: $var2";
echo "</body></html>";
?>


Now this particular config file is in a well known location in a popular application.

The web server has access to it, since it has to be able to read the file for proper execution when you run the script on your site. I should not be able to get to your files from the server when run from my site, but due to the nature of the shared server, I can see it.

Now there is an Apache directive that will force PHP to stay home; that is not allow PHP to read files outside of a base directory. That will stop me from including your file from a script in my directory from PHP. I don't think it stops me from opening the same file from Perl though.

-t

I did miss what you said, I've been tired the last few days and posting here anyway -- which is probably a bad idea. Did you see the former parts of the thread explaining the use of groups and users? Wherein it was discussed that you set the Apache web server to run as a certain user an a different group? Apache itself will run as "anotheruser", yet run as "anothergroup". That's to say, PHP will run as "anotheruser", but not as "anothergroup". PHP scripts wouldn't have access, since the user's home directory is owned by username.anothergroup and has the permissions set to 710 and PHP is running as the "otheruser" user. This should deny anyone but Apache and that account owner to access that dir and any files within it -- since PHP runs as the user of Apache, it can't access the group that Apache is using, unless it's Apache itself accessing it.

Maybe I'm wrong, I haven't tested it, but that's the idea and it can be worked around. In otherwords, PHP running as nobody, can't include a file that is in a directory set at 710 and owned by someotherusername.apachegroup (which is an Apache group different from the Apache user). If you've tested it and still could read/include other user's files, let me know. If nothing else and it still did get through and ran as the group, you could do some type of tweaking to the groups file on the system to restrict the user's somehow.

I did see the former posts, and they make perfect sense for denying access to telnet or ftp users, but not Apache.

Since Apache needs to be able to include the PHP file in my directory when running from my domain, on a shared server Apache can still include the file when running from another domain, unless Apache now also runs as a new user.

If the files are not available to the Apache user, the script will fail when run from my domain as well.

The only fix I can see is running all my PHP scripts with Apache suEXEC as me. Then I can lock down the ownership, and prevent anyone else from viewing them at all - including Apache when running as nobody.

Unless there is a way to prevent my home directory from being accessed from anyone outside my domain, I don't see how you can do this with protections alone.

An Apache directive that kept the web server process entirely in my directory tree (and the system cgi tree) when running in my virtual server environment would be great.

My hosting company has set up a specific directory in my account where suEXEC (cgiWrap?) will execute scripts as me. The problem with this approach of course, is now all my scripts need to live in this same directory. That makes for great difficulty managing my site.

-t

ps Get some sleep man!:)

PHP may have the answer...
If you can get your host to do something like open_basedir="." in php.ini, in addittion to what Tim has suggested with permissions.

The open_basedir="." prevents PHP scripts from requiring files outside the directory the script itself is in, so it may break a lot of scripts, but on servers where multiple domains/users are running under the same Apache binary there are not many options for limiting PHP to the user's own directories. This option, while somewhat severe, does seem to accomplish that.

The base dir option can be set in the Apache Virtualhost section as well, but it only effects PHP.

I can still open the PHP files using the open command in Perl and read the contents.

Doesn't solve the problem of the web server being able to read the files in other people's directories.

-t

What I had meant to say, more simply, was that you needn't worry about Apache's 'user' being able to access the files, because it can still, if Apache can -- which Apache can by the 'group' only and have Apache's 'user' still denied -- which will deny people running scripts under Apache's 'user' (they won't be running them as Apache's 'group').

You only deny everyone but _your_ user and Apache's _group_ from accessing your main /home/username dir (this includes not allowing "nobody" (for example) access, yet allowing "nogroup" to _have_ access. Once Apache's "group" can access the main directory, it can access files below that in the path. If someone runs a PHP script to include your file in your directory, it will run as Apache's user, not Apache's group, so it won't have the same access that Apache does. I hope that made more sense, and I haven't fully tested this, just throwing out ideas, but I believe it should work.

It's too bad the server you're on doesn't just make all user's run as their UID/GID with SuEXEC as a default configuration. Even if other user's aren't, you can still have your account/domain allow SuEXEC for all CGI files in your account directory without affecting any other users or being restricted to one sole directory to use this feature. Of course, it sounds like a Cpanel server, yueagghk... Anywya, I'll try and get some time [and sleep] to test this theory out and let you know for sure if it does indeed solve that problem...

This was a very interesting thread, indeed. So the best way to go would be as Tim said?

chmod 711 /home
chmod 750 /home/username
chown username.nogroup /home/username

This will not even let the users see the other account names, which makes it pretty impossible for them to just guess what directories to open even from a perl/php script.

Originally posted by zolbian
This was a very interesting thread, indeed. So the best way to go would be as Tim said?

chmod 711 /home
chmod 750 /home/username
chown username.nogroup /home/username

This will not even let the users see the other account names, which makes it pretty impossible for them to just guess what directories to open even from a perl/php script.

I haven't really seen any other ideas presented. And, for what the original problem was, this is a sound solution, as far as I'm aware. I would suggest trying to set the permissions on the /home/username directory at 710, if you can (And you should be able to fine at that point). Setting the /home directory (or any that you can) to 711 in place of 755 to not let people know the location of files, isn't a bad idea, and I don't see why it would be. However, user's can still have a CGI or PHP (or whatever) script open up your /etc/passwd file (for example) and there's a list of user's accounts and home directory paths.

From there, it's pretty easy to guess the path to /home/theirusername/public_html/path/to/some/file (espexially if you visit their web site). Of course, they can't do that, since this solution I speak of will deny them that. Also, user's can get this same information from the web server's configuration file (also in a pretty common place and not difficult to find anyway). So, make sure you use SuEXEC, change the group of the web server, change the ownership and permission on the propor files -- and although this (and rarely is anything) the be all, end all solution to protecting user's from each other -- it's one good, simple step that anyone can implement to help in that aspect.

Note, this might very well screw things up on a Cpanel server. The way Cpanel runs and how it uses global scripts and whatnot. However, some of that can be gotten around, but Cpanel is built and configured to not really allow people very many easy solutions like this simple issue, without making you have to make some changes. These are small issues, but it's worth mentioning so no one finds out they can't go to the path to the domain.com/cpanel without creating a different redirect script (or having the current one copies into the user's home directory) -- which is simple enough. (of course, there's other problems, like the mailing list (or was it autoresponders?) that will need to be reconfigured to run off the new group Apache does. Other than that and copying global files into the user's home directory to run off of their user and not error, I think that would be about the only changes that's have to be made to not get any errors due to the Cpanel difference -- but I haven't really tested that yet.

Speaking of chroot, where can I get my hands on a good chroot shell so users can't browse around my system looking for things? Is this recommended?

Also, is chroot not enough?

Originally posted by Tim_Greer
Set Apache to run as user "nobody" and the group as "safegrp" or something. Add that group (safegrp) and do:

chmod 711 /home
chmod 750 /home/username
chown username.safegrp /home/username


Does user "username" have to belong to the "safegrp" group or is that undesirable?

Skeptical, use should be in his own group.


Tim_Greer, suEXEC does not work with mod_php, does it? That is what I have installed.

Originally posted by Skeptical


Does user "username" have to belong to the "safegrp" group or is that undesirable?

If all the user's were added to the safegrp group, then all the user's would have the same access as the web server and therefore defeat the purpose. If however, you would want a certain user to be able to browse the user directories for some reason, yes, simply add them to the safegrp. Safegrp is still limited to not being able to view files in the main directory though and will still have it's limitations, but this is a given.

Originally posted by zolbian
Skeptical, use should be in his own group.


Tim_Greer, suEXEC does not work with mod_php, does it? That is what I have installed.

I think that was a neglected thought on my part. Of course using CGI-ed PHP would work, but that defeats the purpose of the Apache module and would be considerably slower. I think there's a PHPwrapper available that can be used to have it basically run as an SUEXEC-ed PHP, but still be a PHP module. I'll let you know if I find out what it was... but something that does come to mind, is phpsuexec or phpscripthash and along those lines as well. http://www.scl.co.uk/scripthash/

Originally posted by Skeptical
Speaking of chroot, where can I get my hands on a good chroot shell so users can't browse around my system looking for things? Is this recommended?

Also, is chroot not enough?

Chroot's can usually, if not always, be broken out of. However, I'd tend to think a well written chroot program would be unable to be circumvented. I don't know of any programs off hand, usually people just write them. I'd recommend this, and it's always a good idea, unless the program in question creates an exploit -- but I'm not aware of any (or many) chroot programs that have had such a result. Chroot is a good idea, but as usual, one thing is never enough. You still need to cover the basics and general issues as well, but a few (or many) well thought out implementations should very much so add to the security of the server... and if nothing else, at least on a user level.

Tim's solution violates filesystem standards and isn't compliant.

look into setting the "setgid" bit on files....it'll let apache view files that others can't depending on your setup.

the easiest is to just disallow group directory browsing and just let them "guess" at index.html or whatever...

-davidu

Originally posted by DavidU
Tim's solution violates filesystem standards and isn't compliant.


How exactly is this not compliant? Explain how this is going to have any adverse effects or why this would be a poor idea to implement. Why in the world would this violate any "filesystem standard" and result in being "noncompliant"? Explain.


look into setting the "setgid" bit on files....it'll let apache view files that others can't depending on your setup.


"Depending on your setup", that goes without saying. If Apache runs as the same user for everyone's PHP (or even CGI) scripts, then that user must have read access (at least) to be able to run it. If it does and runs as the same user, without changing the user at some point, then either no one (including that user's site) or everyone, including all the user's using PHP, CGI, whatever, will be able to view the file by having their PHP script open up the other person's file. Most file systems are structured in a manner to allow people to know where files are, especially by visiting the other user's web site and exploring -- then they'll know the path.. also by viewing the web server configuration and other means. This is the most simple thing that most people are clued in enough to do. I offered a solution so other user's can't use any means to view (or anything else) any other user's files or anything in their directory via a CGI script, shell access, FTP, etc. How does this solution you offer even do that much, let alone stop people from creating PHP scripts to view other user's files? Again, how is what I mentioned a file system violation against the standards and results in being incompatiable? How is that possible? Care to explain?


the easiest is to just disallow group directory browsing and just let them "guess" at index.html or whatever...

-davidu

No, DavidU, that is not true. We're not talking about "directory browsing" via the web, nor are we talking about denying user's to view the files in other user's directories via shell or a script. That's a given anyway, but not needed in a lot of cases. Furthermore, as I said earlier, a simple exploring of someone's web site will give you an idea where almost all their files are located (the exact path to them, in fact), and there are also programs that can be compiled and ran on one user's account to actually guess and find files in any directory that has permissions set to deny the files listed within it. Nay, there are better solutions, but I'm curious to know of exactly what reasons you have for saying my previous solution would violate filesystem standards and create any type of compatiability issues? Is this because some programs need to have read, write or execute access on the user's account? If so, what sort of program would that be? A 3rd party program and that program can easily be allowed access without any other change, than adding the user and/or group that program runs as, to the safegrp group. The point here was to deny everyone but relevant programs, the web server and the user access and no one else (and nothing else) unless you specifically want to. That's the angst of security. I'd appreciate you being clear about what you meant when you stated that about my previous (albeit, definitely not the be all, end all) solution... especially how your suggestion would even help? Thanks.

Originally posted by Tim_Greer


How exactly is this not compliant? Explain how this is going to have any adverse effects or why this would be a poor idea to implement. Why in the world would this violate any "filesystem standard" and result in being "noncompliant"? Explain.

Example: When I write backup scripts -- and I expect certain (perhaps even unwritten) rules to be folowed along the filesystem to maintain permissions -- this would cause me a great deal of headache.


"Depending on your setup", that goes without saying. If Apache runs as the same user for everyone's PHP (or even CGI) scripts, then that user must have read access (at least) to be able to run it. If it does and runs as the same user, without changing the user at some point, then either no one (including that user's site) or everyone, including all the user's using PHP, CGI, whatever, will be able to view the file by having their PHP script open up the other person's file. Most file systems are structured in a manner to allow people to know where files are, especially by visiting the other user's web site and exploring -- then they'll know the path.. also by viewing the web server configuration and other means. This is the most simple thing that most people are clued in enough to do. I offered a solution so other user's can't use any means to view (or anything else) any other user's files or anything in their directory via a CGI script, shell access, FTP, etc. How does this solution you offer even do that much, let alone stop people from creating PHP scripts to view other user's files? Again, how is what I mentioned a file system violation against the standards and results in being incompatiable? How is that possible? Care to explain?


Ok, here's a quickie that takes no user intervention:

when their account is created, make their public_html or whatever mode 2750 (setting the setgid bit) and make it group owner wwwuser or something. A group they aren't in but the webserver is. They have full read/write ownership in there, they just won't be group owner.



No, DavidU, that is not true. We're not talking about "directory browsing" via the web, nor are we talking about denying user's to view the files in other user's directories via shell or a script. That's a given anyway, but not needed in a lot of cases. Furthermore, as I said earlier, a simple exploring of someone's web site will give you an idea where almost all their files are located (the exact path to them, in fact), and there are also programs that can be compiled and ran on one user's account to actually guess and find files in any directory that has permissions set to deny the files listed within it. Nay, there are better solutions, but I'm curious to know of exactly what reasons you have for saying my previous solution would violate filesystem standards and create any type of compatiability issues? Is this because some programs need to have read, write or execute access on the user's account? If so, what sort of program would that be? A 3rd party program and that program can easily be allowed access without any other change, than adding the user and/or group that program runs as, to the safegrp group. The point here was to deny everyone but relevant programs, the web server and the user access and no one else (and nothing else) unless you specifically want to. That's the angst of security. I'd appreciate you being clear about what you meant when you stated that about my previous (albeit, definitely not the be all, end all) solution... especially how your suggestion would even help? Thanks.

If you think we're talking about directory browsing via the web or something, you got lost. ;-)

Our technique is similar but if I am not mistaken, in your way the user has the ability to change their mode and thus cause support headaches...in my way with the setgid bit sticky, they have to perform "additional" steps to FORCE the mode -- something no ftp client or local file editor would do on its own.

That's all...hopefully this respnse didn't get b0rked...

davidu

Originally posted by DavidU

Example: When I write backup scripts -- and I expect certain (perhaps even unwritten) rules to be folowed along the filesystem to maintain permissions -- this would cause me a great deal of headache.



First of all, what you're talking about "unwritten rules" and something unique, then you've certainly do things to either adhere to or avoid certain problems due to this. Why (I'm curious) would this have any affect on permissions? Make changes accordingly, if needed. This isn't an issue even you should worry about, I'd not think anyway.



Ok, here's a quickie that takes no user intervention:

when their account is created, make their public_html or whatever mode 2750 (setting the setgid bit) and make it group owner wwwuser or something. A group they aren't in but the webserver is. They have full read/write ownership in there, they just won't be group owner.


This is basically and near exactly what I had said, did you read my posts?


If you think we're talking about directory browsing via the web or something, you got lost. ;-)


No, I didn't. I just wasn't sure what you were saying, so I mentioned both, just in case, as I assumed you were lost. Go figure. :-)


Our technique is similar but if I am not mistaken, in your way the user has the ability to change their mode and thus cause support headaches...in my way with the setgid bit sticky, they have to perform "additional" steps to FORCE the mode -- something no ftp client or local file editor would do on its own.

That's all...hopefully this respnse didn't get b0rked...

davidu

No, I understand, thanks for responding. I agree with the sticky bit, but I had the impression that you were saying it would be better to not set directory's that are relevant with a different user and/or group for the web server. So, I guess you did read my posts, but I thought you simply said that it wouldn't work. My mind works differently, I guess, as I would have understood what you were saying more clearly, if you simply said "Yes, do that, but set the sticky bit to this, so the user can't change it". I was, for the sake of clarity, speaking about the user's main account directory anyway, and when it's created. Therefore, any file they uploaded or created (or directory) wouldn't need any changing, etc. Also, if a user changed their group on their main account dir, which you could allow them the choice -- which was probably why I didn't suggest what you did, then it would seem that they wanted to, as I can't imagine any user doing it on purpose. Of course, are we talking about changing the ownership or permissions here? And, do we want to allow people the choice? I'd let them, based on how it was set up, of course, so they'd only change that if they knew they wanted to. Maybe that last part just now, didn't make any sense? Oh well. Thanks for clearing that up.

Also, another (main) reason I said the user's account directory, was because enough ISP's still house script aliased directory's in the /home/useraccount/script_alias_dir instead of within the public_html directory, which I personally think is a much better way -- for many reasons I won't bother getting into. There's also the issue of custom web root's and other script aliased directories and aliases alone that might be neglected on a very many number of hosts.

I was wondering, how does control panels do this? Are they using suEXEC for their file manager or something? Also how do they prevent people from taking the whole thing and using it on another server?

Originally posted by zolbian
I was wondering, how does control panels do this? Are they using suEXEC for their file manager or something? Also how do they prevent people from taking the whole thing and using it on another server?

Do you mean keep user's on the system from copying the source for the control panel, or the person that runs the server? Or, are you talking about something else entirely? Most control panel's I've seen that run file managers, you can simply type in a path to any file you want that whatever the control panel and/or file manager has permission to see, execute or write to, depending. Obviously most people don't have control panel programs on their own accounts and it's a global program (usually ran as a deamon to accept connections and is usually ran as root). Many of them are compiled, and compiled on/for that system. Some do license checking as well. Although you could grab the source and copy it if it were C source, Perl, Python, whatever and install and run it.

Also, the license checking could liely easily be cracked, but few do that anyway. If you have source or a global program, such as a control panel, just have it owned by root (or another user with certain priveledges would be better) and have the permissions deny anyone but that user to be able to view, read, write or execute the file(s)/program(s). Depending on the control panel, there might be nothing to stop a user on the system from grabbing the source code and running it on another system. I think people might notice eventually though, but maybe not. Depending on how it's coded, what language it's coded in and the ownership and permissions of the files and directories, there might be nothing stopping any user from doing anything they want. Of course, that goes for any program/script, depending on how it's coded, configured and permissions and ownership. If someone's smart, they won't just be running it in a manner that would allow anyone any way to do such a thing, but again, some don't.

If we take CPanel for example, how is it coded and ran? Can the server admin copy the source to another server and run it there?

The reason why I ask this is because we're coding a new shopping cart for hosting companies. This cart will basicly be installed in one place and everyone will be using it (done with Alias cart/ /path/to/cart). It is so to make things as easy as possible for the server admin. We are writing this cart in PHP with MySQL database.

Our concern is how we can protect the source of these scripts since at least one of them contains some sensitive information (mysql/admin login and password, etc). Users will not know where this script is installed, but they can run a Perl script as apache and look at httpd.conf to find the path. We just want to make this as secure as possible.

I would appriciate any help/suggestions.

Originally posted by zolbian
If we take CPanel for example, how is it coded and ran? Can the server admin copy the source to another server and run it there?

The reason why I ask this is because we're coding a new shopping cart for hosting companies. This cart will basicly be installed in one place and everyone will be using it (done with Alias cart/ /path/to/cart). It is so to make things as easy as possible for the server admin. We are writing this cart in PHP with MySQL database.

Our concern is how we can protect the source of these scripts since at least one of them contains some sensitive information (mysql/admin login and password, etc). Users will not know where this script is installed, but they can run a Perl script as apache and look at httpd.conf to find the path. We just want to make this as secure as possible.

I would appriciate any help/suggestions.

Cpanel is compiled, although it uses some scripts (shell and Perl scripts) for something or another.. I don't know or care what though... but their main program, I think, is compiled. I don't think you'd be able to just copy it and run it on another server. I do understand what you mean though. I'd not consider on coding anything in PHP, if I was worried about passwords or any type of sensitive information being had. Or, I'd run it as CGI and not an Apache module -- since the shopping carts and control panel's and the like don't get accessed enough to take a performance hit, but it will also not allow any other user's on the system (that I know of, I'm not a huge fan of PHP -- I mean, I code in it, use it, configure, install it, etc. but I'd prefer alternatives) to have to use PHP as CGI and not as an Apache module. I'd personally code things in C for the best and most secure performance and have it be compiled source (Note: C in itself is not going to provide better security, don't misunderstand me there). I believe there are some tools for PHP (ran as a module and/or CGI) that will basically encrypt the PHP code. I will try and find the link to that. It seems odd that PHP isn't designed to run in some wrapper mode by the developers. In regards to this, I'm not sure what to suggest, let me think about it. Maybe someone else in the meantime can suggest something?

Most of the scripts are just fine coded in PHP. There is only one file that keeps a little sensetive information that we have to find a solution for.

The thing is, from what I have understood, webservers are not safe at all. There is no good way to protect your files from others on the same server. Which I think should be the developers top priority to find a solution for next release (of Apache/Linux/Unix).

Originally posted by zolbian
Most of the scripts are just fine coded in PHP. There is only one file that keeps a little sensetive information that we have to find a solution for.

The thing is, from what I have understood, webservers are not safe at all. There is no good way to protect your files from others on the same server. Which I think should be the developers top priority to find a solution for next release (of Apache/Linux/Unix).

Well, if you're only worried about one file that's included that houses the password for the account or database or whatever and not your source code, then I can still see where you're coming from. Webserver's are certainly not completely safe in that aspect. Certain things have been implemented though, of course, such as SuEXEC for CGI. This would stop someone from viewing a CGI script due to how user's can set more restrictive permissions on their script. PHP doesn't allow this, without being CGI or having some sort of wrapper itself or something to encrypt the code. PHP itself poses the problem here, as opposed to CGI. Of course, we all know how PHP compares to CGI.

If you had the means, you'd be better off hacking the PHP (and possibly Apache) source and compiling it to work how you want -- I haven't looked much at the PHP source, but some of Apache, or to write or modify your own Apache module. However, and of course, neither of those are valid options for someone that wnats to just simply sell a script (or give it away) where people are stuck with having to use the generic software and generic installs. Certainly that poses a problem and risk. From a software developer point of view, all you or I can do, is suggest people configure things a certain way -- IF they have the permission. We are basically stuck with using basic things that a user could change on their regular account. I.e., permissions. There's no much you can do.

If you offer a program/script that will be installed from the server administrative point of view, you have more options, of course. Such as telling them a solution, such as we're trying to find here and now, and/or having some install script make these changes for them, but in a manner that wouldn't possibly alter or harm or change the fucntion of anything else. This isn't an easy thing when dealing with something like Apache and PHP of all things. Apache (I feel, personally) is more suited for that sort of thing by being able to write your own Apache module and that would be the end of it.

My only suggestion at this point, is to run another web server and since it's a shopping cart, it can be Apache-SSL (which you'll want anyway) or another verion of Apache that makes use of SSL. Simply run it on another port as to not conflict with the current web server (Likely Apache too), and have this web server run off a complete different user and group. Deny any user and group permission to go into this other web server's directory root but that web server's user/group (of course) and no one but root and that web server would have any way of viewing any of the PHP code or anything else in that directory (or anything beyond it). Just set it to 700 or something. Maybe lower, actually. Just whatever you can work with and deny all other user's. That is the only solution I can think of at 5 AM that is simple and workable without any problems that you are concerned about.

Tim,

I really appriciate it that you take time to help us and answer our questions.

This last solution with 2 apache servers, would this work with Alias cart/ /path/to/cart?

The first solution with 1 apache server I think is pretty secure as well. To find out the password and such, the users needs to know how to program, how to find http.conf and what to look for in that file. But still, it's not 100% safe.

Tim,

I think we're on the same wavelength now. I certainly think all of the methods you have suggested are better then the "option of using SuExec". SuExec is a real hassle and a security nightmare.

I'm glad there are people like you in the forums posting and hopefully I'll be able to help in the same way.

-davidu

Originally posted by DavidU
Tim,

I certainly think all of the methods you have suggested are better then the "option of using SuExec". SuExec is a real hassle and a security nightmare.

-davidu

Maybe I missed something, but... I don't think Tim was suggesting that you NOT use Su_exec. SuExec is actually a integral part of the security model Tim proposed. I set up systems using a similar (well almost exact) permission structure to what Tim has outlined, and it seems to work very well. Su_exec serves to limit CGI process (eg. perl scripts) to files and processes owned by the account in question, And PHP when run as non-CGI can be pretty well limited using safe_mode and/or open_basedir config settings.

There are other aspects that need to be considered too, such as allowing Apache to follow symlinks, aliasing of directories etc. I have seen cases -many of them in fact - where it appeared that users were pretty well limited to their own directories, except that they were allowed to create a symlink to a directory outside of "their" directory tree, and all efforts to limit them via the above methods were nullified.

By controlling the "Options" directives available to users via .htaccess, this can be overcome too, without limiting users too much, but it does take careful thought and planning to restrict users to only the files and processes they need without compromising the other users security. If you are running all of your accounts under a single, shared httpd binary, and you have "AllowOverRide all" in your httpd.conf file, you probably should take another look at your security setup. SymLinksIfOwnerMatch is a good alternative to FollowSymLinks, but make sure that you don't allow your users to override it in one of their own directories.

To sum it up... the permission structure Tim outlined is a good starting point for security on shared servers, Su_exec or some other wrapper like it is I would say almost mandatory, PHP config settings eed to be carefully implemented, as well as Apache configs, but if you can think it all through, it IS possible to set up a shared hosting environment that prevents most of the obvious security holes being discussed here.

John

Originally posted by zolbian
Tim,

I really appriciate it that you take time to help us and answer our questions.

This last solution with 2 apache servers, would this work with Alias cart/ /path/to/cart?

The first solution with 1 apache server I think is pretty secure as well. To find out the password and such, the users needs to know how to program, how to find http.conf and what to look for in that file. But still, it's not 100% safe.

You can have both Apache servers use that alias path and go to different places. One Apache will work by default as http://www.domain.tld/cart/, which the other Apache server will call it like http://www.domain.tld:port/cart/ ... You won't want them both to point to the same place, because your other Apache used for the cart, will be running under another user and group and deny permissions to any other user and group, so one web server can't read the other's file/dir, which is what you want -- since that second one will not have other user's having access to it to be able to read/grab the files in question. You can do a redirect with the first Apache to have /cart/ be an alias to the other Apache server and include the port number, so it can do a proper redirect without having to specify the port number each time to access the proper server in question.

Also, it's not difficult at all to find the paths or the location of the web server configuration file by any means, it's usually located in one of two very common places and it's not difficult to find the path. However, you can set your web server configuration directory and/or files to deny permissions to anyone but root to read it and this will deny people the ability to be able to view it anyway -- which it a definite suggestion to do, even if you make no other changes. Most ammature's that snoop around for web files, will know right where it is and be able to view it. May as well deny them that ability, as they have no legitimate reason to want to.

Originally posted by DavidU
Tim,

I think we're on the same wavelength now. I certainly think all of the methods you have suggested are better then the "option of using SuExec". SuExec is a real hassle and a security nightmare.

I'm glad there are people like you in the forums posting and hopefully I'll be able to help in the same way.

-davidu

Elsmore1 was correct in stating that I was still for using SuEXEC. I realize it can impose some security issues, but that's only if it's not installed properly. I've personally installed (Well, compiled into the web server) SuEXEC on too many servers to count. It's not a difficult thing to do at all or configure properly. Once it is, it improves security. The only drawback is that a poorly coded CGI script using it, will have the same privledges as the very user, which means if someone can exploit that user's CGI script, that user can have his/her site wiped out. Without SuEXEC, no matter what we do to get around the file viewing problem, another using would then be able to view another's CGI files running as the Apache user, which would otherwise be prevented due to SuEXEC. I definitely don't think SuEXEC is the only solution or anything, but it's a plus and a positive thing, if you ask me and the only realistic means around the problem people were speaking about -- in addition to what we've been discussing as well. Personally, I'm going to develop some type of wrapper that will work on a web and system level, without the need to worry about SuEXEC, global settings and user's, etc. or being forced to have different user's with different web servers.

Tim,

I understand exactly what you mean. That is a very good solution to this, thank you.

This is how some control panels work as well I assume, this way they can have one apache run as root and have access to everyones files.

I was wondering, is it possible to use a seperate file for domains/subdomians instead of putting everything in httpd.conf? Like is there an include()/require() command for httpd.conf?

Originally posted by zolbian
Tim,

I understand exactly what you mean. That is a very good solution to this, thank you.

This is how some control panels work as well I assume, this way they can have one apache run as root and have access to everyones files.

I was wondering, is it possible to use a seperate file for domains/subdomians instead of putting everything in httpd.conf? Like is there an include()/require() command for httpd.conf?

No, don't (and you don't need to anyway) run the other web server as root. Add a group and user, called, well, whatever you want to call them. Don't run a web server as root though. Also, you can (and with both web servers, or just one) use chroot to jail it into a certain directory path and user, so any exploit on the web server that could ever be used, will greatly limit what damage would be done.

Some control panel's have their own mini web server. For example Cpanel. Basically, it's just C or Perl (or another) code that opens up a port and accepts socket connections to be able to have an interface -- much like Apache would do, but less complex. Apache might be a better idea and run as root, in place of some common code that's run for a control panel, but with some mini web server you can code or modify (you could do the same with Apache's code, but that would take _a while_!), and you have only the interfaces and privledges and whatnot that you want and have better control -- since obviously this control panel interface will need some access beyond a regular user, but be careful if you run it as root. Likely, you could just create another user and give it better access, but not completely root access -- this would entail modifying ownership and permissions on certain files, but better that access than the entire system.


Yes, you can use separate files instead of having a huge httpd.conf file by itself an I'd personally suggest it even. it makes things a lot easier to manage, it's a lot cleaner too. You just include files that have the same type of directives in it. I'm not sure of any limitations that might or might not be affected, but some might exist -- but they also might not. I haven't witnessed any. Yes, that's a good option and I'd suggest using it. For more and better explanations than those that I could give, check out http://www.apache.org and see their documentation.

Just a stupid question from me;

Can I chmod the root dir to 711 ?
It's for a cpanel server.

thank you,
Domenico

I just wanted to post a couple of thoughts after reading this thread.

First, I agree with Tim so far, most notably on file/directory permissions. I don't see how adhereing to some unwritten "filesystem standards" could take precedence over security.

suEXEC is absolutely necessary -- otherwise CGI scripts would break right through the system previously mentioned. PHP I'm still torn on... I hate safe_mode, but currently it seems to be the only secure way (though I'll be looking into phpsuexec...)

The point that got my interest here was about the unwritten filesystem rules, which are inherently non-secure. There are a lot of unwritten rules that I personally break:

- Use Bind
- Use Sendmail
- Run Apache as 'nobody'

I refuse to use these long-standing rules simply because there are much more secure (and less buggy) ways of doing things. I'd rather spend a few hours learning how to do it right, than to just do it the way everyone else does it. I'd rather use TinyDNS, Qmail, and run services under a dedicated user (eg 'apache').

Change sucks, but is sometimes necessary. This is why we have shadow passwords, sticky bits, pop-before-smtp, and other things that changed the "standard" way of doing things in favor of security.

I don't know why this thread resurfaced, but while it's alive...

Originally posted by Jm4n
suEXEC is absolutely necessary -- otherwise CGI scripts would break right through the system previously mentioned. PHP I'm still torn on... I hate safe_mode, but currently it seems to be the only secure way (though I'll be looking into phpsuexec...)


I agree entirely about using suexec, but, err, why treat PHP any differently from any other CGI scripts? Build a commandline PHP interpreter and run them through suexec.

Hrm... what about

chmod 711 /home

And then securing any config/log files that might contain the usernames? I know this probably won't work for systems who foolishly name user home directories in sequential order (why?!), but for those whose home directories are random (their usernames) it tends to keep wandering eyes out. There are ways to get around it, yes, but to a standard user who isn't all that familiar with *nix, it should keep them at bay. It's a simple solution that will _likely_ thwart the wandering eyes of many.

Originally posted by allera
systems who foolishly name user home directories in sequential order (why?!)

Security. If you're writing suid scripts to perform user account maintainance you want to be absolutely certain that someone doesn't do mean things like, say, deleting the root user. Naming all non-system users coherantly makes it easy to check if suid scripts should be touching those users.

It's a simple solution that will _likely_ thwart the wandering eyes of many.

If you just want to keep people out of users' home directories, just chmod them all 700. Personally I don't see a big issue here (although I'd agree that the actual websites should be safe from prying eyes).

alright... this permission things is a rather complicated business... here are what I did to ensure a user cannot see the content of other users' files... ok here we go...

1. run apache as user apache and group apache

2. chgrp each users' homedir to group apache so apache itself can serve files from inside user homedir, AND user cannot see other users' files, just make sure that those users are not belong to group apache, or else... :)

3. configure suexec, so that every cgi scripts run as user... when cgi script runs as user privileges (instead of apache's) it cannot be used to see other users' files

4. do NOT use mod_php or mod_perl or any modules that allows users to execute arbitrary code from inside apache, as they can be used to steal other users' files

5. DO NOT UNDER ANY CIRCUMSTANCES run BOTH mod_php (or similar, see #4) AND suexec, doing so will bypass an important security check in suexec... it you desperately need mod_php, make sure to enable safe mode... (running without mod_php or similar is MUCH MUCH safer)

6. use Option FollowSymlinksIfOwnerMatch in httpd.conf, doing so will prevent apache to follow symlink to another file IF the owners of both file differ... this will prevent user creating symlinks to another user's file to see the contents of that file...

7. use AllowOverride -Options, so that user will not be able to change Options settings (see #6) in a .htaccess file

8. HOWEVER, those people with smart minds in Microsoft decided to use Option directive in EVERY &%#*($& .htaccess file, go figure! now if you do #7, those accounts with Frontpage extension will not work... my solution is to patch apache so that Option FollowSymlinksIfOwnerMatch is always in effect regardless what Options directive says (although I would prefer patching Frontpage extension)

alright, that's all folks...

If a user doesn't have permission to do anything with a file, that user can't link to it either. They can create a broken symlink, but a quick test shows that even with Options FollowSymLinks, a user can't view files in another user's directory.

Just make sure that, along with all of the above, you set the user home directories to mode 0750.

Hrm... what about

chmod 711 /home
I do this along with the above. But this alone only keeps them from viewing the directories -- once I know a username, I can go in. This is as simply as 'cat /etc/passwd', which for various reasons has to remain world-readable.

Security through obscurity is just no good -- someone someday will find what you're hiding, and exploit that. Plus, this particular issue is very common, a lot of machines are set up this way. Once I know a username, I can go in and find (as an example) scriptname.php, complete with MySQL username and password. Not to mention potential credit card numbers; obviously much more sensitive information is also available.

Regarding PHP, if run in safe_mode *and* the open_basedir directive is set on a per-site basis (via admin_php_value in each <VirtualHost> container), it can be relatively safe to run.

<EDIT>
Something I just though about: what about keeping the user home directories under that user's user and group ownership, and adding user 'apache' to each of the groups? Is there any performance hit by having one user in many groups? Is there any specific limit on how many groups a user can be in?

The reason this might be better is that you can now create sub-users if, for example, a user wants to allow an FTP-only user with specific permissions. Simply add them to the primary user's group, and they can have access...

I've tested this, and it seems to be just as secure as having the group owner as 'apache', plus I can create sub-users for any domain account...

Any thoughs on this?
</EDIT>

The only point to running PHP, is to save the overhead that CGI creates. Otherwise, I don't see the point. Of course, you can embed CGI scripts into some Apache module like FastCGI and/or mod_perl, etc., but then you have the same problem that PHP creates.

Barring a hack to the PHP code to somehow enforce some rules by some generic wrapper, there's not too much we can do, assuming we want to reap the benefits and reason that makes PHP any good to even bother to use anyway.

That said, I'm really waiting, almost impatiently for Apache 2.x to come out and be stable one day... why? Well, because it will solve all of the problem discussed here (assuming you take other common steps are well, of course), because Apache 2.x will run each Vhost as a the account's own user. That's to say, what SuEXEC does for CGI, Apache already will do this for each virtual host, without any modifications to the code! Yes, that's right, in case I'm not being clear -- any process that user's domain/Vhost runs, will be ran under THEIR username. This would be for CGI, PHP, mod_perl, FastCGI, etc.

Therefore, not only can we use the ideas about with the permissions, group, ownership, etc., but a permission of 710 or 750 on the user's home directory (with only their user and group) can be made to work, if it doesn't already. Nonetheless, the idea's discussed above will work. Add to that, great control now, since you have control over individual processes, not just CGI processes, of the user.

This means control over the user's PHP scripts when PHP is used as a module, not just as CGI with SuEXEC and it's limitation feature. This will be great to do all around per Vhost, rather than Apache in whole. Great control and power now and much more secure in other ways too, not just for the user accounts.

I like this idea, because it offers control and security and much more, while not requiring anything to change and be able to take full advantage of what some of these modules are meant for (to save resources) and have all the control you need now. So, that with some other ideas above, along with a chroot jail on Apache, if relevant, would really solve some problems.

Still, that in addition with other common ideas and system wide wrappers and chrooting for shell access and other programs as well, will be a big help. Sure, some of the stuff is basic, but some of the stuff can't truly secure the server on a shared hosting environment, until Apache 2.x is finally stable. I am really looking forward to that day.

Has anyone set up tims idea sucesfully on a cpanel server without breaking anything?

Not even going to try. :D

chmod 711 /home
chmod 711 /home/user
chmod 755 /home/user/public_html

There is the way to give shell access to people so they can't browse in other dirs:
1) Use SuEXEC
2) Create group "www"
3) All users should be in group "www"
4) chmod 701 each user's dir
5) problem solved :D
They will browse, but they can't see what is in dir since permissions are 701 :D

Touching a cpanel server can be a nightmare :rolleyes: where things are not documented on the server side.

But I'm trying ;)

Another problem at cpanel server is php code in cpanel themes. Can not protect it. :bawling:

We chroot our users in every environment. telnet/ssh, FTP, PHP/CGI. Nobody has any chance of getting out their home directory with anything.

Is anyone else doing this?

I've setup a partially chrooted environment, however SSH is currently not chrooted.

I have been playing with it on my tester box, but I haven't got it as secure, reliable and feature-rich as I'd like.

Could you explain the resources you've used or the methods you've followed to achieve this chroot bliss?


------
Jason

Without giving away too much, the basic story is that each users' homedir is actually an NFS-mounted 'jail' which contains the /bin, /dev, and /lib stuff necessary for a shell session, and their own little private copy of /etc/passwd with just their user in it. So that takes care of shells.

FTP is chrooted via the built in capabilities of ProFTPd.

Web scripts (PHP, Perl, Ruby, Python, etc) are chrooted (and the processes "chowned") via SuExec/Sbox.

It took months of debugging when we first got started, but now it's quite a robust, developer-friendly environment.

Originally posted by magnafix
Without giving away too much, the basic story is that each users' homedir is actually an NFS-mounted 'jail' which contains the /bin, /dev, and /lib stuff necessary for a shell session, and their own little private copy of /etc/passwd with just their user in it. So that takes care of shells.


A few questions come to mind. You cannot run PHP as a module, correct? NFS doesn't give you file-locking, correct? You have to watch NFS for its own security problems (ooh boy is that the truth). Where does e-mail live? Where does e-mail get processed, eg via procmail? Are you using jail or chroot? jail is more what you need. chroot isn't, really. Do you see significant overhead with all of this, or from the NFS dependency? And finally, why NFS at all?

Kevin

We run PHP both as a module and CGI. 99% of our customers use the CGI version though (private /etc/php.ini, no 'safe mode', paths are same as shell, scripts run as your user).

Email lives on another server altogether unconnected to the web cluster.

NFS has some overhead, and we had to put Miva on the local hard drive of one webserver, but everything else seems to be running fine. The webservers handle 10-15 hits/second during peak times and are only moderately loaded.

This setup allows us to have a big SCSI RAID-5 fileserver and a bunch of cheap (~1k) webservers. As traffic grows, we just add webservers to the cluster pretty painlessly.

So... so far so good. :)

You can limit via PHP which files can be opened via open_basedir !

You can use it within vhost configurations in apache, I used on my server.

<VirtualHost 1.2.3.4>
ServerName www.domain.com
DocumentRoot /home/username/www
php_admin_value open_basedir "/home/username:/tmp"
</VirtualHost>

that will stop people from including/fopen-ing/etc files that arent in /home/username or /tmp

More: http://www.php.net/manual/en/configuration.php#ini.open-basedir

The Time is October 2002: You have been awakend to check on the status of the security of using PHP and Apache.
With the release of Apache 2.0 and PHP 4. some odd number.some revision that is BETA, has anything changed in the aspect of having unsecure PHP running amuck?

Originally posted by hKey_LM_32
The Time is October 2002:

If you could wait one day+ more, it would have been November 2002. :)

I think another good option is to chroot the users home directory to the website root. In this option the only thing you need to do is creat a bin directory in there website root with only the utilities they need and have it only runnable by that user. proftpd does this with ftp. Very safe. "As a note people usually run chrooted named daemons now as well."

I think this is the best option because there are other major security problems related to letting users have shell access to your system via ssh.

Hope this helps.

I'm looking at getting my own dedicated server and I am going to need a control panel as I wll have a few clients hosted. I'm not in the hosting business so much as I like to host my own design/programming clients so that I have more control.

I'm very concerned about security and admitedly don't understand everything that has been said in this thread.

I spent the entire night last night reading about different control panels and the controversary over the whole topic.

I was thinking of using Ensim and wondering how it measured up security wise. Also, I have read that it is very much tied into the OS and makes it difficult to make changes.

Jennifer

I haev not heard anything positive about Ensigm (If i spelled it right). From what I have seen CPanel is the one everybdoy raves about and Plesk 5.0 (the version coming out) is supposed to be much better then the prior one but i have also heard alot of negative things about it .

Security Wise I honestly would not endorse any of them though from what i have read up on them and security.

I want to enable root telnet for everyone.

I think Ensigm lets you do that. I recently went into somebody who was using Ensigm and the telnet was rooted and belonged and ran under root privileges lol. I guess a "Thank God for Idiots" is probably in store for that company as i could have thought of some not so nice things to do there