[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]

Originally Posted by 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.
...
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]

Originally Posted by QuantumNet

... 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]

Originally Posted by 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???

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/0...c-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