Topic: ibay security

[Mike Stoddart]

Say I have an ibay, Bob, which contains a copy of PHPNuke (not that I use it, but at least people are familiar with it).

I then create a new ibay called Fred. I created Fred to host some scripts for a friend (who is strangely called Fred). Now what is to stop Fred writing a PHP or Perl script to 'cat' the contents of the PHPNuke configuration file that contains the database username and password? I can't restrict his read access to only his ibay, at least I don't think I can.

How can I stop anything like this from happening?
Thanks
Mike

[Rick]

Make a group with one member: Fred and assign this group to the Ibay

I think that's the solution.

[Dan McGarry]

Hi Mike;

e-smith is aware of the vulnerability that you're discussing. It's an issue that every web server administrator has to deal with, by the way. The general issue runs something like this:

As soon as you begin trusting users to create scripts using technologies such as PHP and SSI, you have to take into account that any information on my system that's world-readable can be displayed, even if it isn't otherwise accessible via HTTP, and even if it's protected from direct access using web server access control.

PHP, SSI and a number of other methods of creating dynamic content all allow data on the local file system to be read, as long as the file system permissions allow access to the userid the script is using. Typically, this is the userid that the web server itself runs as. e-smith's web server runs as user www.

If you do not want to allow anyone to use PHP in i-bays, follow these instructions:

1) Log into the e-smith console as user root.

2) If one does not already exist, create a custom template directory for your httpd.conf file:

mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/

3) Create an empty file named 75AddType00PHP:

cd /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/

touch 75AddType00PHP

4) Update the server configuration:

/sbin/e-smith/signal-event console-save

There are options available to security-conscious web server administrators that allow scripts to be run under more controlled conditions. Feel free to post to the experienced user forum, or to the devinfo mailing list for advice and instructions.

e-smith has been studying this problem, and we expect to have a patch that allows better administrative control over use of dynamic scripting very soon.