Any Security issues with Shared Hosting Plans?

mbstevens wrote:
> On Thu, 31 Aug 2006 23:34:49 -0400, Jerry Stuckle wrote:
>
>
>>mbstevens wrote:
>>
>>>On Thu, 31 Aug 2006 22:04:50 -0400, Jerry Stuckle wrote:
>>>
>>>
>>>
>>>>But it does not stop a Perl or PHP program, for instance, running on one
>>>>virtual host from accessing the files on another virtual host.
>>>>
>>>>All virtual host run as the same user - the Apache user. So any script
>>>>running under Apache can access any file in any virtual host (as long as
>>>>that file is available to the specific virtual host, of course).
>>>
>>>
>>>Wrappers lower that risk.
>>>The machine's administrator can use suEXEC to set up each virtual host so
>>>that that host executes its CGI programs via a user chosen by the
>>>administrator. Any nastiness of a CGI is limited to that user's
>>>privileges. (The server must be built with suEXEC enabled.)
>>>
>>>
>>>
>>
>>That's true - if you're running SuSE, and if you're running as CGI.
>>
>>But most sites, for instance, run PHP as an apache extension, not CGI,
>>for performance reasons. And a most of them don't run SuSE.
>>
>>However, I will grant you that if they really understand what they're
>>doing, they will run SuSE and CGI - and just not as many sites on the
>>server (running as a CGI has more overhead than as an Apache extension).
>
>
> I don't think suEXEC has any particular relation to SuSE. The naming
> probably has to do with a relation to the su command, which allows
> a regular user to execute particular programs as the administrator.
> Ubuntu, for instance, does all administration through su as default,
> instead of having you log in as root user. suEXEC is just a program that
> Apache must be configured to use.
>
> Another wrapper is CGIWrap.
>
>
>
>
>

Oops, you're right. Sorry, got them confused.

However - there are major limitations in using PHP as a CGI, also.
Additionally, performance is much worse running PHP as a CGI.

And not knowing how SUEXEC works, I'm not positive you could configure
it like you say. The only real difference would be different
directories and virtual hosts; PHP is generally set up for the entire
machine.

However, as I said, I'm not sure on this part. But it's almost a moot
point anyway since most hosting companies don't run PHP as a CGI.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex.TakeThisOut@attglobal.net
==================
 >> Stay informed about: Any Security issues with Shared Hosting Plans? 

David Hennessy wrote:
> Jerry Stuckle wrote:
>
>> mbstevens wrote:
>>
>>> On Thu, 31 Aug 2006 23:34:49 -0400, Jerry Stuckle wrote:
>>>
>>>
>>>> mbstevens wrote:
>>>>
>>>>> On Thu, 31 Aug 2006 22:04:50 -0400, Jerry Stuckle wrote:
>>>>>
>>>>>
>>>>>
>>>>>> But it does not stop a Perl or PHP program, for instance, running
>>>>>> on one virtual host from accessing the files on another virtual host.
>>>>>>
>>>>>> All virtual host run as the same user - the Apache user. So any
>>>>>> script running under Apache can access any file in any virtual
>>>>>> host (as long as that file is available to the specific virtual
>>>>>> host, of course).
>>>>>
>>>>>
>>>>>
>>>>> Wrappers lower that risk.
>>>>> The machine's administrator can use suEXEC to set up each virtual
>>>>> host so
>>>>> that that host executes its CGI programs via a user chosen by the
>>>>> administrator. Any nastiness of a CGI is limited to that user's
>>>>> privileges. (The server must be built with suEXEC enabled.)
>>>>>
>>>>>
>>>>>
>>>>
>>>> That's true - if you're running SuSE, and if you're running as CGI.
>>>>
>>>> But most sites, for instance, run PHP as an apache extension, not
>>>> CGI, for performance reasons. And a most of them don't run SuSE.
>>>>
>>>> However, I will grant you that if they really understand what
>>>> they're doing, they will run SuSE and CGI - and just not as many
>>>> sites on the server (running as a CGI has more overhead than as an
>>>> Apache extension).
>>>
>>>
>>>
>>> I don't think suEXEC has any particular relation to SuSE. The naming
>>> probably has to do with a relation to the su command, which allows a
>>> regular user to execute particular programs as the administrator.
>>> Ubuntu, for instance, does all administration through su as default,
>>> instead of having you log in as root user. suEXEC is just a program
>>> that Apache must be configured to use.
>>>
>>> Another wrapper is CGIWrap.
>>>
>>>
>>>
>>
>> Oops, you're right. Sorry, got them confused.
>>
>> However - there are major limitations in using PHP as a CGI, also.
>> Additionally, performance is much worse running PHP as a CGI.
>>
>> And not knowing how SUEXEC works, I'm not positive you could configure
>> it like you say. The only real difference would be different
>> directories and virtual hosts; PHP is generally set up for the entire
>> machine.
>>
>> However, as I said, I'm not sure on this part. But it's almost a moot
>> point anyway since most hosting companies don't run PHP as a CGI.
>>
>
>
> There's always the PHP open_basedir protection... if the host is running
> cPanel, they can enable it with a single click.
>
>

And how will that keep someone else on the same server from accessing
your files?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex.DeleteThis@attglobal.net
==================
 >> Stay informed about: Any Security issues with Shared Hosting Plans? 

Jerry Stuckle wrote:
> mbstevens wrote:
>> On Thu, 31 Aug 2006 23:34:49 -0400, Jerry Stuckle wrote:
>>
>>
>>> mbstevens wrote:
>>>
>>>> On Thu, 31 Aug 2006 22:04:50 -0400, Jerry Stuckle wrote:
>>>>
>>>>
>>>>
>>>>> But it does not stop a Perl or PHP program, for instance, running
>>>>> on one virtual host from accessing the files on another virtual host.
>>>>>
>>>>> All virtual host run as the same user - the Apache user. So any
>>>>> script running under Apache can access any file in any virtual host
>>>>> (as long as that file is available to the specific virtual host, of
>>>>> course).
>>>>
>>>>
>>>> Wrappers lower that risk.
>>>> The machine's administrator can use suEXEC to set up each virtual
>>>> host so
>>>> that that host executes its CGI programs via a user chosen by the
>>>> administrator. Any nastiness of a CGI is limited to that user's
>>>> privileges. (The server must be built with suEXEC enabled.)
>>>>
>>>>
>>>>
>>>
>>> That's true - if you're running SuSE, and if you're running as CGI.
>>>
>>> But most sites, for instance, run PHP as an apache extension, not
>>> CGI, for performance reasons. And a most of them don't run SuSE.
>>>
>>> However, I will grant you that if they really understand what they're
>>> doing, they will run SuSE and CGI - and just not as many sites on the
>>> server (running as a CGI has more overhead than as an Apache extension).
>>
>>
>> I don't think suEXEC has any particular relation to SuSE. The naming
>> probably has to do with a relation to the su command, which allows a
>> regular user to execute particular programs as the administrator.
>> Ubuntu, for instance, does all administration through su as default,
>> instead of having you log in as root user. suEXEC is just a program
>> that Apache must be configured to use.
>>
>> Another wrapper is CGIWrap.
>>
>>
>>
>>
>
> Oops, you're right. Sorry, got them confused.
>
> However - there are major limitations in using PHP as a CGI, also.
> Additionally, performance is much worse running PHP as a CGI.
>
> And not knowing how SUEXEC works, I'm not positive you could configure
> it like you say. The only real difference would be different
> directories and virtual hosts; PHP is generally set up for the entire
> machine.
>
> However, as I said, I'm not sure on this part. But it's almost a moot
> point anyway since most hosting companies don't run PHP as a CGI.
>


There's always the PHP open_basedir protection... if the host is running
cPanel, they can enable it with a single click.


--
David J. Hennessy
http://david.maidix.com/
 >> Stay informed about: Any Security issues with Shared Hosting Plans? 

David Hennessy wrote:
> Jerry Stuckle wrote:
>
>> David Hennessy wrote:
>>
>>> Jerry Stuckle wrote:
>>>
>>>> mbstevens wrote:
>>>>
>>>>> On Thu, 31 Aug 2006 23:34:49 -0400, Jerry Stuckle wrote:
>>>>>
>>>>>
>>>>>> mbstevens wrote:
>>>>>>
>>>>>>> On Thu, 31 Aug 2006 22:04:50 -0400, Jerry Stuckle wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> But it does not stop a Perl or PHP program, for instance,
>>>>>>>> running on one virtual host from accessing the files on another
>>>>>>>> virtual host.
>>>>>>>>
>>>>>>>> All virtual host run as the same user - the Apache user. So any
>>>>>>>> script running under Apache can access any file in any virtual
>>>>>>>> host (as long as that file is available to the specific virtual
>>>>>>>> host, of course).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Wrappers lower that risk.
>>>>>>> The machine's administrator can use suEXEC to set up each virtual
>>>>>>> host so
>>>>>>> that that host executes its CGI programs via a user chosen by the
>>>>>>> administrator. Any nastiness of a CGI is limited to that user's
>>>>>>> privileges. (The server must be built with suEXEC enabled.)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> That's true - if you're running SuSE, and if you're running as CGI.
>>>>>>
>>>>>> But most sites, for instance, run PHP as an apache extension, not
>>>>>> CGI, for performance reasons. And a most of them don't run SuSE.
>>>>>>
>>>>>> However, I will grant you that if they really understand what
>>>>>> they're doing, they will run SuSE and CGI - and just not as many
>>>>>> sites on the server (running as a CGI has more overhead than as an
>>>>>> Apache extension).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I don't think suEXEC has any particular relation to SuSE. The naming
>>>>> probably has to do with a relation to the su command, which allows
>>>>> a regular user to execute particular programs as the administrator.
>>>>> Ubuntu, for instance, does all administration through su as default,
>>>>> instead of having you log in as root user. suEXEC is just a
>>>>> program that Apache must be configured to use.
>>>>>
>>>>> Another wrapper is CGIWrap.
>>>>>
>>>>
>>>> Oops, you're right. Sorry, got them confused.
>>>>
>>>> However - there are major limitations in using PHP as a CGI, also.
>>>> Additionally, performance is much worse running PHP as a CGI.
>>>>
>>>> And not knowing how SUEXEC works, I'm not positive you could
>>>> configure it like you say. The only real difference would be
>>>> different directories and virtual hosts; PHP is generally set up for
>>>> the entire machine.
>>>>
>>>> However, as I said, I'm not sure on this part. But it's almost a
>>>> moot point anyway since most hosting companies don't run PHP as a CGI.
>>>>
>>>
>>>
>>> There's always the PHP open_basedir protection... if the host is
>>> running cPanel, they can enable it with a single click.
>>>
>>>
>>
>> And how will that keep someone else on the same server from accessing
>> your files?
>>
>
>
> It will keep them from opening files outside of their home directory
> with PHP. Then you've got jailshell SSH, and an FTP server that
> restricts access based on permissions... it's definitely doable.
>
>

And how will it do that? Every site is running under the same user id -
Apache's. And all sites must be readable by the Apache user.

And we aren't talking about FTP or SSH. We're taking about the web server.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex RemoveThis @attglobal.net
==================
 >> Stay informed about: Any Security issues with Shared Hosting Plans? 

Jerry Stuckle wrote:
> David Hennessy wrote:
>> Jerry Stuckle wrote:
>>
>>> mbstevens wrote:
>>>
>>>> On Thu, 31 Aug 2006 23:34:49 -0400, Jerry Stuckle wrote:
>>>>
>>>>
>>>>> mbstevens wrote:
>>>>>
>>>>>> On Thu, 31 Aug 2006 22:04:50 -0400, Jerry Stuckle wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> But it does not stop a Perl or PHP program, for instance, running
>>>>>>> on one virtual host from accessing the files on another virtual
>>>>>>> host.
>>>>>>>
>>>>>>> All virtual host run as the same user - the Apache user. So any
>>>>>>> script running under Apache can access any file in any virtual
>>>>>>> host (as long as that file is available to the specific virtual
>>>>>>> host, of course).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Wrappers lower that risk.
>>>>>> The machine's administrator can use suEXEC to set up each virtual
>>>>>> host so
>>>>>> that that host executes its CGI programs via a user chosen by the
>>>>>> administrator. Any nastiness of a CGI is limited to that user's
>>>>>> privileges. (The server must be built with suEXEC enabled.)
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> That's true - if you're running SuSE, and if you're running as CGI.
>>>>>
>>>>> But most sites, for instance, run PHP as an apache extension, not
>>>>> CGI, for performance reasons. And a most of them don't run SuSE.
>>>>>
>>>>> However, I will grant you that if they really understand what
>>>>> they're doing, they will run SuSE and CGI - and just not as many
>>>>> sites on the server (running as a CGI has more overhead than as an
>>>>> Apache extension).
>>>>
>>>>
>>>>
>>>> I don't think suEXEC has any particular relation to SuSE. The naming
>>>> probably has to do with a relation to the su command, which allows a
>>>> regular user to execute particular programs as the administrator.
>>>> Ubuntu, for instance, does all administration through su as default,
>>>> instead of having you log in as root user. suEXEC is just a program
>>>> that Apache must be configured to use.
>>>>
>>>> Another wrapper is CGIWrap.
>>>>
>>>>
>>>
>>> Oops, you're right. Sorry, got them confused.
>>>
>>> However - there are major limitations in using PHP as a CGI, also.
>>> Additionally, performance is much worse running PHP as a CGI.
>>>
>>> And not knowing how SUEXEC works, I'm not positive you could
>>> configure it like you say. The only real difference would be
>>> different directories and virtual hosts; PHP is generally set up for
>>> the entire machine.
>>>
>>> However, as I said, I'm not sure on this part. But it's almost a
>>> moot point anyway since most hosting companies don't run PHP as a CGI.
>>>
>>
>>
>> There's always the PHP open_basedir protection... if the host is
>> running cPanel, they can enable it with a single click.
>>
>>
>
> And how will that keep someone else on the same server from accessing
> your files?
>


It will keep them from opening files outside of their home directory
with PHP. Then you've got jailshell SSH, and an FTP server that
restricts access based on permissions... it's definitely doable.


--
David J. Hennessy
http://david.maidix.com/
 >> Stay informed about: Any Security issues with Shared Hosting Plans? 

David Hennessy wrote:
> Jerry Stuckle wrote:
>
>> David Hennessy wrote:
>>
>>> Jerry Stuckle wrote:
>>>
>>>> David Hennessy wrote:
>>>>
>>>>> Jerry Stuckle wrote:
>>>>>
>>>>>> mbstevens wrote:
>>>>>>
>>>>>>> On Thu, 31 Aug 2006 23:34:49 -0400, Jerry Stuckle wrote:
>>>>>>>
>>>>>>>
>>>>>>>> mbstevens wrote:
>>>>>>>>
>>>>>>>>> On Thu, 31 Aug 2006 22:04:50 -0400, Jerry Stuckle wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> But it does not stop a Perl or PHP program, for instance,
>>>>>>>>>> running on one virtual host from accessing the files on
>>>>>>>>>> another virtual host.
>>>>>>>>>>
>>>>>>>>>> All virtual host run as the same user - the Apache user. So
>>>>>>>>>> any script running under Apache can access any file in any
>>>>>>>>>> virtual host (as long as that file is available to the
>>>>>>>>>> specific virtual host, of course).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Wrappers lower that risk.
>>>>>>>>> The machine's administrator can use suEXEC to set up each
>>>>>>>>> virtual host so
>>>>>>>>> that that host executes its CGI programs via a user chosen by the
>>>>>>>>> administrator. Any nastiness of a CGI is limited to that user's
>>>>>>>>> privileges. (The server must be built with suEXEC enabled.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's true - if you're running SuSE, and if you're running as CGI.
>>>>>>>>
>>>>>>>> But most sites, for instance, run PHP as an apache extension,
>>>>>>>> not CGI, for performance reasons. And a most of them don't run
>>>>>>>> SuSE.
>>>>>>>>
>>>>>>>> However, I will grant you that if they really understand what
>>>>>>>> they're doing, they will run SuSE and CGI - and just not as many
>>>>>>>> sites on the server (running as a CGI has more overhead than as
>>>>>>>> an Apache extension).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I don't think suEXEC has any particular relation to SuSE. The
>>>>>>> naming
>>>>>>> probably has to do with a relation to the su command, which
>>>>>>> allows a regular user to execute particular programs as the
>>>>>>> administrator.
>>>>>>> Ubuntu, for instance, does all administration through su as default,
>>>>>>> instead of having you log in as root user. suEXEC is just a
>>>>>>> program that Apache must be configured to use.
>>>>>>>
>>>>>>> Another wrapper is CGIWrap.
>>>>>>>
>>>>>>
>>>>>> Oops, you're right. Sorry, got them confused.
>>>>>>
>>>>>> However - there are major limitations in using PHP as a CGI, also.
>>>>>> Additionally, performance is much worse running PHP as a CGI.
>>>>>>
>>>>>> And not knowing how SUEXEC works, I'm not positive you could
>>>>>> configure it like you say. The only real difference would be
>>>>>> different directories and virtual hosts; PHP is generally set up
>>>>>> for the entire machine.
>>>>>>
>>>>>> However, as I said, I'm not sure on this part. But it's almost a
>>>>>> moot point anyway since most hosting companies don't run PHP as a
>>>>>> CGI.
>>>>>>
>>>>>
>>>>>
>>>>> There's always the PHP open_basedir protection... if the host is
>>>>> running cPanel, they can enable it with a single click.
>>>>>
>>>>>
>>>>
>>>> And how will that keep someone else on the same server from
>>>> accessing your files?
>>>>
>>>
>>>
>>> It will keep them from opening files outside of their home directory
>>> with PHP. Then you've got jailshell SSH, and an FTP server that
>>> restricts access based on permissions... it's definitely doable.
>>>
>>>
>>
>> And how will it do that? Every site is running under the same user id
>> - Apache's. And all sites must be readable by the Apache user.
>>
>> And we aren't talking about FTP or SSH. We're taking about the web
>> server.
>>
>
> I guess the best answer I have is, "Very well."
>
> On my box, Apache runs as nobody. The user & group that owns the
> directory of a particular virtual host, as well as the open_base_dir
> settings, are specified in the virtual host section. So, PHP knows if
> your site is in "/home/user1/public_html" and you're trying to access a
> script in "/home/user2/public_html". I restrict it to not allow outside
> access, unless specifically overriden for a particular directory.
>
> [Someone please correct me if I have the mechanics wrong here!]
>
> I've got it set up on my shared box, and it works as advertised.
>

So you're saying that a php script from one site cannot access the pages
of another site on the same server?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex RemoveThis @attglobal.net
==================
 >> Stay informed about: Any Security issues with Shared Hosting Plans? 

Jerry Stuckle wrote:
> David Hennessy wrote:
>> Jerry Stuckle wrote:
>>
>>> David Hennessy wrote:
>>>
>>>> Jerry Stuckle wrote:
>>>>
>>>>> mbstevens wrote:
>>>>>
>>>>>> On Thu, 31 Aug 2006 23:34:49 -0400, Jerry Stuckle wrote:
>>>>>>
>>>>>>
>>>>>>> mbstevens wrote:
>>>>>>>
>>>>>>>> On Thu, 31 Aug 2006 22:04:50 -0400, Jerry Stuckle wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> But it does not stop a Perl or PHP program, for instance,
>>>>>>>>> running on one virtual host from accessing the files on another
>>>>>>>>> virtual host.
>>>>>>>>>
>>>>>>>>> All virtual host run as the same user - the Apache user. So
>>>>>>>>> any script running under Apache can access any file in any
>>>>>>>>> virtual host (as long as that file is available to the specific
>>>>>>>>> virtual host, of course).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Wrappers lower that risk.
>>>>>>>> The machine's administrator can use suEXEC to set up each
>>>>>>>> virtual host so
>>>>>>>> that that host executes its CGI programs via a user chosen by the
>>>>>>>> administrator. Any nastiness of a CGI is limited to that user's
>>>>>>>> privileges. (The server must be built with suEXEC enabled.)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> That's true - if you're running SuSE, and if you're running as CGI.
>>>>>>>
>>>>>>> But most sites, for instance, run PHP as an apache extension, not
>>>>>>> CGI, for performance reasons. And a most of them don't run SuSE.
>>>>>>>
>>>>>>> However, I will grant you that if they really understand what
>>>>>>> they're doing, they will run SuSE and CGI - and just not as many
>>>>>>> sites on the server (running as a CGI has more overhead than as
>>>>>>> an Apache extension).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I don't think suEXEC has any particular relation to SuSE. The naming
>>>>>> probably has to do with a relation to the su command, which allows
>>>>>> a regular user to execute particular programs as the administrator.
>>>>>> Ubuntu, for instance, does all administration through su as default,
>>>>>> instead of having you log in as root user. suEXEC is just a
>>>>>> program that Apache must be configured to use.
>>>>>>
>>>>>> Another wrapper is CGIWrap.
>>>>>>
>>>>>
>>>>> Oops, you're right. Sorry, got them confused.
>>>>>
>>>>> However - there are major limitations in using PHP as a CGI, also.
>>>>> Additionally, performance is much worse running PHP as a CGI.
>>>>>
>>>>> And not knowing how SUEXEC works, I'm not positive you could
>>>>> configure it like you say. The only real difference would be
>>>>> different directories and virtual hosts; PHP is generally set up
>>>>> for the entire machine.
>>>>>
>>>>> However, as I said, I'm not sure on this part. But it's almost a
>>>>> moot point anyway since most hosting companies don't run PHP as a CGI.
>>>>>
>>>>
>>>>
>>>> There's always the PHP open_basedir protection... if the host is
>>>> running cPanel, they can enable it with a single click.
>>>>
>>>>
>>>
>>> And how will that keep someone else on the same server from accessing
>>> your files?
>>>
>>
>>
>> It will keep them from opening files outside of their home directory
>> with PHP. Then you've got jailshell SSH, and an FTP server that
>> restricts access based on permissions... it's definitely doable.
>>
>>
>
> And how will it do that? Every site is running under the same user id -
> Apache's. And all sites must be readable by the Apache user.
>
> And we aren't talking about FTP or SSH. We're taking about the web server.
>

I guess the best answer I have is, "Very well."

On my box, Apache runs as nobody. The user & group that owns the
directory of a particular virtual host, as well as the open_base_dir
settings, are specified in the virtual host section. So, PHP knows if
your site is in "/home/user1/public_html" and you're trying to access a
script in "/home/user2/public_html". I restrict it to not allow outside
access, unless specifically overriden for a particular directory.

[Someone please correct me if I have the mechanics wrong here!]

I've got it set up on my shared box, and it works as advertised.

--
David J. Hennessy
http://david.maidix.com/
 >> Stay informed about: Any Security issues with Shared Hosting Plans? 

David Hennessy wrote

> On my box, Apache runs as nobody. The user & group that owns the
> directory of a particular virtual host, as well as the open_base_dir
> settings, are specified in the virtual host section. So, PHP knows if
> your site is in "/home/user1/public_html" and you're trying to access
> a script in "/home/user2/public_html". I restrict it to not allow
> outside access, unless specifically overriden for a particular
> directory.
>
> [Someone please correct me if I have the mechanics wrong here!]
>
> I've got it set up on my shared box, and it works as advertised.

That's how I understand it. I have my own box, but I enabled the
open_basedir protection. I figured it was a good habit to get into.

--
Charles Sweeney
http://CharlesSweeney.com
 >> Stay informed about: Any Security issues with Shared Hosting Plans? 

Jerry Stuckle wrote:
> David Hennessy wrote:
>> Jerry Stuckle wrote:
>>
>>> David Hennessy wrote:
>>>
>>>> Jerry Stuckle wrote:
>>>>
>>>>> David Hennessy wrote:
>>>>>
>>>>>> Jerry Stuckle wrote:
>>>>>>
>>>>>>> mbstevens wrote:
>>>>>>>
>>>>>>>> On Thu, 31 Aug 2006 23:34:49 -0400, Jerry Stuckle wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> mbstevens wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, 31 Aug 2006 22:04:50 -0400, Jerry Stuckle wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> But it does not stop a Perl or PHP program, for instance,
>>>>>>>>>>> running on one virtual host from accessing the files on
>>>>>>>>>>> another virtual host.
>>>>>>>>>>>
>>>>>>>>>>> All virtual host run as the same user - the Apache user. So
>>>>>>>>>>> any script running under Apache can access any file in any
>>>>>>>>>>> virtual host (as long as that file is available to the
>>>>>>>>>>> specific virtual host, of course).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Wrappers lower that risk.
>>>>>>>>>> The machine's administrator can use suEXEC to set up each
>>>>>>>>>> virtual host so
>>>>>>>>>> that that host executes its CGI programs via a user chosen by the
>>>>>>>>>> administrator. Any nastiness of a CGI is limited to that user's
>>>>>>>>>> privileges. (The server must be built with suEXEC enabled.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That's true - if you're running SuSE, and if you're running as
>>>>>>>>> CGI.
>>>>>>>>>
>>>>>>>>> But most sites, for instance, run PHP as an apache extension,
>>>>>>>>> not CGI, for performance reasons. And a most of them don't run
>>>>>>>>> SuSE.
>>>>>>>>>
>>>>>>>>> However, I will grant you that if they really understand what
>>>>>>>>> they're doing, they will run SuSE and CGI - and just not as
>>>>>>>>> many sites on the server (running as a CGI has more overhead
>>>>>>>>> than as an Apache extension).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think suEXEC has any particular relation to SuSE. The
>>>>>>>> naming
>>>>>>>> probably has to do with a relation to the su command, which
>>>>>>>> allows a regular user to execute particular programs as the
>>>>>>>> administrator.
>>>>>>>> Ubuntu, for instance, does all administration through su as
>>>>>>>> default,
>>>>>>>> instead of having you log in as root user. suEXEC is just a
>>>>>>>> program that Apache must be configured to use.
>>>>>>>>
>>>>>>>> Another wrapper is CGIWrap.
>>>>>>>>
>>>>>>>
>>>>>>> Oops, you're right. Sorry, got them confused.
>>>>>>>
>>>>>>> However - there are major limitations in using PHP as a CGI,
>>>>>>> also. Additionally, performance is much worse running PHP as a CGI.
>>>>>>>
>>>>>>> And not knowing how SUEXEC works, I'm not positive you could
>>>>>>> configure it like you say. The only real difference would be
>>>>>>> different directories and virtual hosts; PHP is generally set up
>>>>>>> for the entire machine.
>>>>>>>
>>>>>>> However, as I said, I'm not sure on this part. But it's almost a
>>>>>>> moot point anyway since most hosting companies don't run PHP as a
>>>>>>> CGI.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> There's always the PHP open_basedir protection... if the host is
>>>>>> running cPanel, they can enable it with a single click.
>>>>>>
>>>>>>
>>>>>
>>>>> And how will that keep someone else on the same server from
>>>>> accessing your files?
>>>>>
>>>>
>>>>
>>>> It will keep them from opening files outside of their home directory
>>>> with PHP. Then you've got jailshell SSH, and an FTP server that
>>>> restricts access based on permissions... it's definitely doable.
>>>>
>>>>
>>>
>>> And how will it do that? Every site is running under the same user
>>> id - Apache's. And all sites must be readable by the Apache user.
>>>
>>> And we aren't talking about FTP or SSH. We're taking about the web
>>> server.
>>>
>>
>> I guess the best answer I have is, "Very well."
>>
>> On my box, Apache runs as nobody. The user & group that owns the
>> directory of a particular virtual host, as well as the open_base_dir
>> settings, are specified in the virtual host section. So, PHP knows if
>> your site is in "/home/user1/public_html" and you're trying to access
>> a script in "/home/user2/public_html". I restrict it to not allow
>> outside access, unless specifically overriden for a particular directory.
>>
>> [Someone please correct me if I have the mechanics wrong here!]
>>
>> I've got it set up on my shared box, and it works as advertised.
>>
>
> So you're saying that a php script from one site cannot access the pages
> of another site on the same server?
>

Yep! This is an essential thing that one should check for on a potential
shared host. I think that this, combined with the aforementioned "fixes"
for other potential vulnerabilities, can make for a safe and secure
shared hosting environment. Of course, there always remains the
possibility of an exploit on the software itself, as with any server
deployment.

--
David J. Hennessy
http://david.maidix.com/
 >> Stay informed about: Any Security issues with Shared Hosting Plans? 

David Hennessy wrote:
> Jerry Stuckle wrote:
>
>> David Hennessy wrote:
>>
>>> Jerry Stuckle wrote:
>>>
>>>> David Hennessy wrote:
>>>>
>>>>> Jerry Stuckle wrote:
>>>>>
>>>>>> David Hennessy wrote:
>>>>>>
>>>>>>> Jerry Stuckle wrote:
>>>>>>>
>>>>>>>> mbstevens wrote:
>>>>>>>>
>>>>>>>>> On Thu, 31 Aug 2006 23:34:49 -0400, Jerry Stuckle wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> mbstevens wrote:
>>>>>>>>>>
>>>>>>>>>>> On Thu, 31 Aug 2006 22:04:50 -0400, Jerry Stuckle wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> But it does not stop a Perl or PHP program, for instance,
>>>>>>>>>>>> running on one virtual host from accessing the files on
>>>>>>>>>>>> another virtual host.
>>>>>>>>>>>>
>>>>>>>>>>>> All virtual host run as the same user - the Apache user. So
>>>>>>>>>>>> any script running under Apache can access any file in any
>>>>>>>>>>>> virtual host (as long as that file is available to the
>>>>>>>>>>>> specific virtual host, of course).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Wrappers lower that risk.
>>>>>>>>>>> The machine's administrator can use suEXEC to set up each
>>>>>>>>>>> virtual host so
>>>>>>>>>>> that that host executes its CGI programs via a user chosen by
>>>>>>>>>>> the
>>>>>>>>>>> administrator. Any nastiness of a CGI is limited to that user's
>>>>>>>>>>> privileges. (The server must be built with suEXEC enabled.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That's true - if you're running SuSE, and if you're running as
>>>>>>>>>> CGI.
>>>>>>>>>>
>>>>>>>>>> But most sites, for instance, run PHP as an apache extension,
>>>>>>>>>> not CGI, for performance reasons. And a most of them don't
>>>>>>>>>> run SuSE.
>>>>>>>>>>
>>>>>>>>>> However, I will grant you that if they really understand what
>>>>>>>>>> they're doing, they will run SuSE and CGI - and just not as
>>>>>>>>>> many sites on the server (running as a CGI has more overhead
>>>>>>>>>> than as an Apache extension).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't think suEXEC has any particular relation to SuSE. The
>>>>>>>>> naming
>>>>>>>>> probably has to do with a relation to the su command, which
>>>>>>>>> allows a regular user to execute particular programs as the
>>>>>>>>> administrator.
>>>>>>>>> Ubuntu, for instance, does all administration through su as
>>>>>>>>> default,
>>>>>>>>> instead of having you log in as root user. suEXEC is just a
>>>>>>>>> program that Apache must be configured to use.
>>>>>>>>>
>>>>>>>>> Another wrapper is CGIWrap.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Oops, you're right. Sorry, got them confused.
>>>>>>>>
>>>>>>>> However - there are major limitations in using PHP as a CGI,
>>>>>>>> also. Additionally, performance is much worse running PHP as a CGI.
>>>>>>>>
>>>>>>>> And not knowing how SUEXEC works, I'm not positive you could
>>>>>>>> configure it like you say. The only real difference would be
>>>>>>>> different directories and virtual hosts; PHP is generally set up
>>>>>>>> for the entire machine.
>>>>>>>>
>>>>>>>> However, as I said, I'm not sure on this part. But it's almost
>>>>>>>> a moot point anyway since most hosting companies don't run PHP
>>>>>>>> as a CGI.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There's always the PHP open_basedir protection... if the host is
>>>>>>> running cPanel, they can enable it with a single click.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> And how will that keep someone else on the same server from
>>>>>> accessing your files?
>>>>>>
>>>>>
>>>>>
>>>>> It will keep them from opening files outside of their home
>>>>> directory with PHP. Then you've got jailshell SSH, and an FTP
>>>>> server that restricts access based on permissions... it's
>>>>> definitely doable.
>>>>>
>>>>>
>>>>
>>>> And how will it do that? Every site is running under the same user
>>>> id - Apache's. And all sites must be readable by the Apache user.
>>>>
>>>> And we aren't talking about FTP or SSH. We're taking about the web
>>>> server.
>>>>
>>>
>>> I guess the best answer I have is, "Very well."
>>>
>>> On my box, Apache runs as nobody. The user & group that owns the
>>> directory of a particular virtual host, as well as the open_base_dir
>>> settings, are specified in the virtual host section. So, PHP knows if
>>> your site is in "/home/user1/public_html" and you're trying to access
>>> a script in "/home/user2/public_html". I restrict it to not allow
>>> outside access, unless specifically overriden for a particular
>>> directory.
>>>
>>> [Someone please correct me if I have the mechanics wrong here!]
>>>
>>> I've got it set up on my shared box, and it works as advertised.
>>>
>>
>> So you're saying that a php script from one site cannot access the
>> pages of another site on the same server?
>>
>
> Yep! This is an essential thing that one should check for on a potential
> shared host. I think that this, combined with the aforementioned "fixes"
> for other potential vulnerabilities, can make for a safe and secure
> shared hosting environment. Of course, there always remains the
> possibility of an exploit on the software itself, as with any server
> deployment.
>

OK, I understand now. I didn't realize you could have a separate
open_base_dir for each virtual host. But can that be overridden by
..htaccess?

Thanks for the info!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex.DeleteThis@attglobal.net
==================
 >> Stay informed about: Any Security issues with Shared Hosting Plans?