open_basedir

[thoroughfare]

Please see:
http://www.webhostingtalk.com/showthread.php?s=&threadid=264033

By default, are DA users protected from this?

Thanks,
Matt :)

[DirectAdmin Support]

Hello,

We do include the code for that, but have it commented out by default. If you want to use it, just run the following:

cd /usr/local/directadmin/data/templates
cp virtual_host*.conf custom
cd custom
perl -pi -e 's/#php_admin_value open_basedir/php_admin_value open_basedir/' virtual_host*.conf
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

John

[thoroughfare]

I have open_basedir turned on (as per your instructions) already, but is it still safe? Please read the whole thread (http://www.webhostingtalk.com/showthread.php?s=&threadid=264033) and you'll see what I mean :)

Thanks again,
Matt

[DirectAdmin Support]

Yes, user1 will be jailed to user2, but that also means user1 shouldn't be able to read any of his own files because he's jailed outside of his home. I don't see a problem. I just confirmed this on my own system.

The guy on WHT might have put the open_basedir restriction at the directory level, not the virtualhost level like we do. If you put the restriction inside the <Directory> directive, then it's only applicable there. We've put it right under the <VirtualHost> directive, so it will affect everything globally accessed via domain.com.

John

[thoroughfare]

Ah ok, thanks John :)

Matt

[jlasman]

What's the concensus?

Does everyone think this is a good idea?

Or a bad one?

Why?

Jeff

[neorder]

any update on this?

[ClayRabbit]

Take a look at my virtual_host.conf

|?DOCROOT=`HOME`/domains/`DOMAIN`/public_html|
|?CGI=+ExecCGI +Includes||?PHP_SAFE_MODE=ON|
<Directory |HOME|>
Options +Indexes |CGI|
<IfModule mod_php4.c>
php_admin_flag engine |PHP|
php_admin_flag safe_mode |PHP_SAFE_MODE|
php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f|USER|"
php_admin_value session.save_path |HOME|/tmp
</IfModule>
</Directory>

<VirtualHost |IP|:80>
|CUSTOM|
ServerName www.|DOMAIN|
ServerAlias www.|DOMAIN| |DOMAIN|
ServerAdmin |ADMIN|
DocumentRoot |DOCROOT|

User |USER|
Group |GROUP|
CustomLog /var/log/httpd/domains/|DOMAIN|.bytes bytes
CustomLog /var/log/httpd/domains/|DOMAIN|.log combined
ErrorLog /var/log/httpd/domains/|DOMAIN|.error.log

<Directory |DOCROOT|>
AllowOverride All
Options +Indexes |CGI|
<IfModule mod_php4.c>
php_admin_flag engine |PHP|
php_admin_flag safe_mode |PHP_SAFE_MODE|
</IfModule>
</Directory>
|HANDLERS|
|MIMETYPES|

</VirtualHost>


If user accessed his site via http://serverip/~username/ then directives defined in his <VirtualHost> HAS NO EFFECT.
To cover that we included <Directory |HOME|> section in virtual_host.conf template (outside the <VirtualHost> section). Directives inside this sections will also affect apropriate VirtualHost's (so we even don't need to override sendmail_path in every VirtualHost of every user's domain/subdomain).

But that issue is only one step to make your system more secure. By default DA comes with very weak PHP-related configurations, so one user can acess files of other user's in several ways.

That's very important question I think, so let's discuss it.
Just a few minutes - I'll try to write below a small article about PHP-security...

[ClayRabbit]

Oh. That's an old thread :) Hope, someone is still care about security... ;)

DirectAdmin Support, unfortunately, open_basedir it's not a jail - that's not enough to cover php security problems.

So. What I know about php-security.
If you are using mod_php an want to prevent users from accessing each other php-scripts and files you have 3 ways:

1. Use mod_become apache module or similar apache patch (with apache childs running under root). Somebody believes it's harmless, someone believes it's dangerous. It's simple and effective, but I'm still affraid to use that solution.

2. Use open_basedir AND disable ALL exec-related php-functions.
If you not disable this functions user is able to exec their own binary or cgi and that process will able to access any files readable by 'apache' user (php-files of any user for exemple).

3. Use safe_mode and define safe_exec_dir.
I think this way is most secure an flexible. User can't access files owned by other users via PHP. And you can put some binaries in safe_exec_dir if you are sure it's safe (such programs must not operate on any files that user may specify).

Besides that, in cases 2. and 3. you also need to disable FollowSymLinks Option in apache (substitute it with SymLinksIfOwnerMatch). If you don't do that, any user will able to read files readable by 'apache' again (not always, but in many situations). Maybe it's also applied to way 1. too (if mod_become doesn't make possible to use 600 permissions on php-files) - I'm not sure.

And additionally, don't forget - compile php with bundled mysql library or disable "LOAD DATA LOCAL" in mysql.

But after all of that you still need to think twice when you are going to add any additional module to php: if functions of that module is dealing with files _directly_ - it can break your security, because safe_mode or open_basedir restrictions will not work for that functions.

BTW, a few days ago i have implemented small patch to safe mode checks in PHP - and now with safe_mode_gid option it causes much less pain to users and still remains very safe =)

That's all. (Hope, I'm not missed anything... ;)
Any additions, suggestions, solutions and advices are welcome :)

[Chrysalis]

hi clayrabbit I agree DA php config is insecure, could you explain how you applied the basedir setting outside the virtual config, you added to main httpd.conf?

[redeye]

I agree with clayrabbit. I've bin looking into this the past few days, and can't get the envoirment secure.

basedir is one thing, but exec, shell_exec etc, ignore this settings. Disabling these features will break (some) scripts. Safe_mode isn't realy a nice option.

I found this maybe someone has experience with this? http://kyberdigi.cz/projects/execdir/english.html

The idea looks good, althought the hacking in the source conserns me.

Found it some more info here: http://www.webhostingtalk.com/showthread.php?threadid=372093&highlight=disable_functions

I know it isn't a problem of DA, but somehow it involves us all, so there is an common interrest :).

Redeye

[sky]

Hello
So is DA realy unsecure even using open_basedir ?

Should i do something more ?

Thx
Sky

[redeye]

It's not that DA is unsecure. In my opinion DA is secure, BUT......

When you setup a webenviorment with DA, (also without), default it will be not an secure webserver implementation. There are several ways to bypass security for customers on a shared server enviorment. What I learned is that it is not a DA issue, but most panels suffer from this.

I find it very hard to secure everything so that there is a good balance between security and functionality.

I think you can create a secure server, but you have to make some offers to functionality that your customers problably not like.

[Chrysalis]

If your question is 'if I enable open_basedir will I be secure' the answer is no. You will be more secure yes but not immune, it just adds a layer of security, you should be adding various layers so it takes longer to peel them away. No server is 100% secure.

[sky]

Ok, thx for your reply's.

I dont like php safe_mode because it is hard for beginners. (i find).

[thoroughfare]

Please see:
http://directadmin.com/forum/showthread.php?s=&threadid=12683

[itmanvn]

Originally posted by ClayRabbit
If user accessed his site via http://serverip/~username/ then directives defined in his <VirtualHost> HAS NO EFFECT.
To cover that we included <Directory |HOME|> section in virtual_host.conf template (outside the <VirtualHost> section). Directives inside this sections will also affect apropriate VirtualHost's (so we even don't need to override sendmail_path in every VirtualHost of every user's domain/subdomain).

But that issue is only one step to make your system more secure. By default DA comes with very weak PHP-related configurations, so one user can acess files of other user's in several ways.

That's very important question I think, so let's discuss it.
Just a few minutes - I'll try to write below a small article about PHP-security... [/B]

Can you help me fix my conf :(

|?DOCROOT=`HOME`/domains/`DOMAIN`/public_html|
<VirtualHost |IP|:80>
|CUSTOM|
|?CGI=ScriptAlias /cgi-bin/ `DOCROOT`/cgi-bin/|
ServerName www.|DOMAIN|
ServerAlias www.|DOMAIN| |DOMAIN| |SERVER_ALIASES|
ServerAdmin |ADMIN|
DocumentRoot |DOCROOT|
|CGI|

|USECANONICALNAME|

SuexecUserGroup |USER| |GROUP|
CustomLog /var/log/httpd/domains/|DOMAIN|.bytes bytes
CustomLog /var/log/httpd/domains/|DOMAIN|.log combined
ErrorLog /var/log/httpd/domains/|DOMAIN|.error.log

<Directory |DOCROOT|>
Options +Includes -Indexes
php_admin_flag engine |PHP|
php_admin_flag safe_mode |SAFE_MODE|
php_admin_value sendmail_path '/usr/sbin/sendmail -t -i -f |USER|@|DOMAIN|'
</Directory>
|HANDLERS|
|MIMETYPES|

php_admin_value open_basedir |HOME|/:/tmp/:/var/www/:/usr/local/lib/php/:/etc/virtual/

</VirtualHost>
<VirtualHost |IP|:80>
ServerName webmail.|DOMAIN|
ServerAdmin |ADMIN|
DocumentRoot /var/www/html/squirrelmail
CustomLog /var/log/httpd/domains/|DOMAIN|.bytes bytes
CustomLog /var/log/httpd/domains/|DOMAIN|.log combined
ErrorLog /var/log/httpd/domains/|DOMAIN|.error.log
</VirtualHost>

[duke28]

hi

with the commande file_get_contents in php

the guys can see all files on the server

i have activate open_basedir in httpd.conf

php_admin_value open_basedir /home/onesusername:/tmp/:/var/www/:/usr/local/lib/php/:/etc/virtual/

how can i protect it ??

why its dont working with open_basedir on the httpd.conf ??

open_basedir not working yet..

[Chrysalis]

is your php version 4.4.x?

[duke28]

yes php4.4.2

[Chrysalis]

I been seeing weird issues with open basedir in 4.4.x and others have also got another bug report going, my bug report keeps been marked as bogus tho the devs are refusing to believe their is a problem that randomly surfaces.

[duke28]

but its the same problem with php5

but its work if i put in the PHP.INI
open_basedir = /home

so now the person is limited to /home ..

its working on the php.ini but not in the virtual host..

[Chrysalis]

what steps did you do to enable in the virtual host?

also do a phpinfo to see if the local value is been set.

[duke28]

i found PHP CGI dont allow openbase_dir in virtual host..

just PHP CLI can do this..


but not normal..

[hehachris]

Originally posted by duke28
i found PHP CGI dont allow openbase_dir in virtual host..

just PHP CLI can do this..


but not normal..
yes
but if you installed suPHP, you can specify a custom php.ini for a domain

[pucky]

There is some weird issue with open_basedir on DA.

We have been running open_basedir on 157 sites on cpanel for years and never had an issue. The moment we moved those sites to DA and enforced open_basedir restrictions on the same, identical websites the following errors were noticed in the logs;

Thousands of these over the course of a month;

[Mon Oct 16 03:32:04 2006] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Oct 16 03:32:04 2006] [notice] Accept mutex: flock (Default: flock)
[Mon Oct 16 03:47:09 2006] [notice] child pid 60218 exit signal Illegal instruction (4)
[Mon Oct 16 03:56:01 2006] [notice] child pid 60267 exit signal Illegal instruction (4)
[Mon Oct 16 03:56:03 2006] [notice] child pid 60260 exit signal Illegal instruction (4)
[Mon Oct 16 03:56:06 2006] [notice] child pid 60213 exit signal Illegal instruction (4)
[Mon Oct 16 03:56:09 2006] [notice] child pid 60214 exit signal Illegal instruction (4)
[Mon Oct 16 03:56:14 2006] [notice] child pid 60219 exit signal Illegal instruction (4)
[Mon Oct 16 03:56:18 2006] [notice] child pid 60603 exit signal Illegal instruction (4)
[Mon Oct 16 03:56:23 2006] [notice] child pid 60266 exit signal Illegal instruction (4)
[Mon Oct 16 03:56:27 2006] [notice] child pid 60268 exit signal Illegal instruction (4)
[Mon Oct 16 03:56:32 2006] [notice] child pid 60265 exit signal Illegal instruction (4)

We searched for almost a month to find the cause of this issue almost restoring our OS. One last and final thing we did not do was remove open_basedir from all the sites.

The moment we did that, Apache stopped seagulfing and core dumping. Not one single illegal instruction message in the logs files after that.

So the 1 million dollar question is this. What is do different between Cpanel and DA open_basedir protection? There should be no difference as we never had Apache issues on Cpanel but under DA we do.

Something is not right with this. If you have 157 website not core dumping Apache on Cpanel then they should not be core dumping Apache on DA unless the open_basedir protection on DA and the way it modified httpd.conf for each virtual site is hosed somewhere.

We almost went out of our minds to find out why these errors were appearing. Can you believe we searched for the cause for 26 days straight? Even got DA involved and they couldnt work out the problem. It was simple. Remove OBD on all sites but that really doesnt explain why Apache core dumps. Doesnt happen on Cpanel. :confused: In order to enforce it on sites we have to do it site by site then watch the logs. What a time consuming chore that will be. Cant image which application on which web site could be the culprit as most people simply run everyday applications and mostly forums. PHPBBS, Invisions and Vbulletin have never causes these issue under OBD. At least not on cpanel.

[toml]

I assume your Cpanel servers were running the same exact version of Apache and PHP on the same OS. Otherwise, I don't think it is fair to try to put the blame on DA. All DA does is package a few scripts to compile Apache/PHP and other modules together.

Illegal instructions usually happen when the system tries to run data as code. This commonly happens when the stack gets overwritten by some bad code. More than likely it is a bug in the version of PHP or some other module loaded in Apache.

The fact that open_basedir causes it to work, might make it appear that is the cause of the problem. The real problem is still happening. Only without the open_basedir, the stack is not getting overwritten, some other memory is in a more benign way.

Doing my search, I saw a few references to upgrade to a snapshot of Php. I wasn't paying attention to the version being used there, but that could be the problem.

[pucky]

OBD is OBD doenst really matters which OS your running. If it doesnt work the site will surely know about it. In this case the site owner was never told of any error otherwise they would have reportedi. Instead. OBD was kicking these erorrs. In fact, on Cpanel we has 8 additional modules compiled into php. We have 8 less than we did on cpanel and the same identical version of php and Apache is running now. The only different being cpanel was being run of Freebsd 5.4 while we are running 6.1 on multiple servers under DA. We run the exact config on 5 others DA servers and this is the only server that producing those errors under OBD. On our other boxes we are running Safe mode and OBD on all boxes. No issues. OBD and Safe mode is disabled on just one box due to errors.

[toml]

Originally posted by pucky
OBD is OBD doenst really matters which OS your running. If it doesnt work the site will surely know about it. In this case the site owner was never told of any error otherwise they would have reportedi. Instead. OBD was kicking these erorrs. In fact, on Cpanel we has 8 additional modules compiled into php. We have 8 less than we did on cpanel and the same identical version of php and Apache is running now. The only different being cpanel was being run of Freebsd 5.4 while we are running 6.1 on multiple servers under DA. We run the exact config on 5 others DA servers and this is the only server that producing those errors under OBD. On our other boxes we are running Safe mode and OBD on all boxes. No issues. OBD and Safe mode is disabled on just one box due to errors.
I really does matter what OS you are running. If you know anything about programming on mulitple platforms, you would know that. I have seen many times code that runs perfect on Solaris fails on AIX or works perfect on HP-UX but fails on Solaris. They all map the stack and heap differently and that is why you see these differences when you have a null or unitialized pointer. If all the other DA servers are the same exact OS/Apache/Php and it runs fine, then I would try updating the OS and rebuilding the customapache and see if that fixes the problem.

[pucky]

We were running Apache 1.3.37 incarnation package on Freebsd 5.4. Today we are running 1.3.37 on Freebsd 6.1 with issues. Maybe its Freebsd maybe its bad code. Wonder why Cpanel never kicked these errors. In any event, we will start adding OBD back on all sites page by page until we start seeing these errors again. Hopefully we can track down the site and find out what they are running.