[solved] Cloudlinux PHP LSAPI "say no to suexec"

[QuantumNet]

Okay well here is a question for you, I have been in a long discussion with Igor regarding suexec vs lsapi php security... Because we are using CageFS the user can only see their own files... but if you use suexec then and attacker can delete a customers site and or easily add malicious code to their files.

Because CageFS already provides the benefit of preventing a user from accessing the other users files, couldnt we just cage php lsapi and not use suexec

here is Igor's response:

You can check with LiteSpeed regarding doing LVE/CageFS without suexec. I believe they might be able to do CageFS without suexec, as they still terminate apache request after it served the request.


Either that or add a suexec ForceUID option just like you have the forcegid option... that way even though we are in suexec mode the user can be forced to something different than the user that owns the files..... this way it since suexec already work in cagefs it would be a no brainer to prevent deletion of files


But isnt it true that LVE controls dont work in suexec mode? so wouldnt my above recommendation of CageFS +php lsapi work with LVE???

 

[QuantumNet]

I love that this product costs $45 a month for a 2cpu license per server... but you cannot even get a response from the staff....

This was once a promising product and I am quickly losing faith in your company

 

[webizen]

Okay well here is a question for you, I have been in a long discussion with Igor regarding suexec vs lsapi php security... Because we are using CageFS the user can only see their own files... but if you use suexec then and attacker can delete a customers site and or easily add malicious code to their files.
...
But isnt it true that LVE controls dont work in suexec mode? so wouldnt my above recommendation of CageFS +php lsapi work with LVE???

suEXEC needs to be enabled for CageFS to work. pls pm the steps to reproduce the issue so we can look into it.

 

[QuantumNet]

I know it currently needs to be enabled... That was not my request... I made a feature request... There is no bug report that needs to ne submitted...

Please take the time to read the request.

 

[webizen]

... but if you use suexec then and attacker can delete a customers site and or easily add malicious code to their files.

...

can you be more specific about this? hence my previous request.

 

[mistwang]

Okay well here is a question for you, I have been in a long discussion with Igor regarding suexec vs lsapi php security... Because we are using CageFS the user can only see their own files... but if you use suexec then and attacker can delete a customers site and or easily add malicious code to their files.

Because CageFS already provides the benefit of preventing a user from accessing the other users files, couldnt we just cage php lsapi and not use suexec

here is Igor's response:

You can check with LiteSpeed regarding doing LVE/CageFS without suexec. I believe they might be able to do CageFS without suexec, as they still terminate apache request after it served the request.


Either that or add a suexec ForceUID option just like you have the forcegid option... that way even though we are in suexec mode the user can be forced to something different than the user that owns the files..... this way it since suexec already work in cagefs it would be a no brainer to prevent deletion of files


But isnt it true that LVE controls dont work in suexec mode? so wouldnt my above recommendation of CageFS +php lsapi work with LVE???

Yes, it is on our to-do list of our lsphp suEXEC daemon development, will be in our 4.2 release.

 

[QuantumNet]

What we were asking is for lsapi php to be caged within cagefs... suexec = bad

and this is why:

any site running suexec is easily hacked because all files are writable by the user so an attacker can install backdoors all over the place even inject malicious code into good code etc

The purpose of suexec is to prevent a php process from reading other users on the files.. but cagefs already does this.

So with lsapi php + cagefs is more secure than using suexec because with this combination no one can read others files and files cannot be written to because php does not execute as the files owners.

CageFS + lsapi php solves the security concerns e have been battling with for years.


Please make lsapi php caged in cagefs not suxec + cagefs

 

[QuantumNet]

any update?

 

[mistwang]

This mode has been added in LSWS 4.2 with PHP suEXEC daemon mode.
http://blog.litespeedtech.com/2012/09/11/lsws-4-2-introduces-php-suexec-daemon-mode/

Once enabled PHP suEXEC daemon mode, you can change "Enable LVE" configuration to "CageFS without suEXEC". If cagefs is disabled for that user or failed to enter the cage, PHP will change user ID (back to default suEXEC mode).

 

[QuantumNet]

This is amazing, it solves security for both server and customer, no longer will people have to settle on a half arse bandaid solution like suexec or suphp

tested and working though you might want to note, for it to work because it forces group nobody... on directadmin servers you must turn off secure access group


@mistwang

thank you so much, is there a chance we can define the group it operates in, instead of group nobody, so we can continue to use secure access group setting in directadmin? its sort of redundant but would be nice to have for users are not mounted in cagefs

 

[mistwang]

set
http://www.litespeedtech.com/docs/webserver/config/extapps/#extUser
http://www.litespeedtech.com/docs/webserver/config/extapps/#extGroup
for lsphp external app, it will be the user/group that all PHP running as.

 

[QuantumNet]

I had tried those before posting, also tried the forcegid option... it seems they work when in normal suexec mode, but they get ignored when in "CageFS without suxec" mode.

Interesting thing is they seem hard coded, the web server runs as
user: apache
group: apache

But when running in "CageFS without suxec" mode. The user and group becomes "nobody"

at it cannot be overidden

I tested this with:

<?php
$user = exec('/bin/id');
echo $user;
?>

 

[mistwang]

You need to set both user/group for external app, only set group wont work.

 

[QuantumNet]

Okay this might shed some light on the problem:

here is the output of test.php
uid=498(apache) gid=500(apache) groups=500(apache)


as you can see the "groups" only shows apache, so the suexec daemon is only picking up the primary group

now lets look at the output of command line:
$ id apache
uid=498(apache) gid=500(apache) groups=500(apache),505(secure)


so here is the problem, suexec daemon needs to pick up all groups it belongs to for secure access group to work correctly

 

[mistwang]

LSAPI 6.0 code has been updated to address this.
you need to rebuild PHP with latest php-lsapi-6.0 code.
Make sure to update /etc/group inside the cage.

 

[QuantumNet]

I installed lsapi 6 when I installed lsws 4.2

here is the output when logged into a user inside cagefs:

[root@sr1 ../php-5.3.x]# su - governme
[governme@sr1 ~]$ php -v
PHP 5.3.9 with Suhosin-Patch (cli) (built: Sep 20 2012 03:35:18)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with the ionCube PHP Loader v4.2.1, Copyright (c) 2002-2012, by ionCube Ltd., and
with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH


[governme@sr1 ~]$ id apache
uid=498(apache) gid=500(apache) groups=500(apache),505(secure)


here is the output of test.php:
uid=498(apache) gid=500(apache) groups=500(apache)






see the groups still only has the apache group, it does not have the secondary group

 

[mistwang]

I installed lsapi 6 when I installed lsws 4.2

lsapi 6 has been updated to address this issue, rebuild your PHP with lsapi 6 again.

 

[QuantumNet]

great works flawlessly... this is a revolution in security... makes suphp and standard suexec look like bandaids


thank you guys so much for this, it is a real game changer for the industry

 

[bettinz]

Hello,
Can someone post a guide about How to correctly enable cagefs without suexec?

If I already have a lot of sites with owner, How can I do that?
I mean: now I've suexec enabled, user john is the owner of john's website folder. If I enable cagefs without suexec, all the files become unwriteable, because litespeed run with user nobody.

How can I use this feature? Is this feature important about security and performance or can I keep suexec enabled?

Thank you

 

[NiteWave]

Can someone post a guide about How to correctly enable cagefs without suexec?

the answer is at #9 reply in this thread.

If I enable cagefs without suexec, all the files become unwriteable, because litespeed run with user nobody.

this is just the purpose of "cagefs without suexec" mode, it's just what some host need. please refer #7 reply in this thread for more detail.

can I keep suexec enabled?

yes. there are 4 choices when set
lsws admin console->Server->General->Cloud Linux:
Disabled
LVE
CageFS
CageFS without suEXEC

generally in shared hosting environment, you should always enable php suExec.
and with this special combination:
LSWS 4.2 with PHP suEXEC daemon mode
+ CageFS without suEXEC

you can have php running as noboby for a user who enabled cageFS.