[BlueOnyx:10168] Re: Trojans and backdoors?

[Steffan]

Thanxs for the answer
Didnt know that suphp allready fixed this problem
I didn't enable suphp for my costumers
In the past ist breaks several things like webmail
And I believe joomla also had problems with this

Is this not an issue anymore on 5107+


-----Oorspronkelijk bericht-----
Van: blueonyx-bounces at mail.blueonyx.it
[mailto:blueonyx-bounces at mail.blueonyx.it] Namens Michael Stauber
Verzonden: woensdag 18 april 2012 11:03
Aan: BlueOnyx General Mailing List
Onderwerp: [BlueOnyx:10167] Re: Trojans and backdoors?

Hi Steffan,

> Is there any reason why below is not a standard on BO ?
>
>> php_flag  php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f
>> the-admin-username-here"

While this is a simple fix, we would have to change the way how we create 
sites.

Say you create a Vsite. The GUI page from which you do this allows you to 
specifly IP, host and domain name, email stuff and which services and
features 
you want to enable for that Vsite. When you click on "save" the Vsite is 
created. 

But at that point we don't have a siteAdmin yet.

So right there we cannot set the php_flag, because for it we would need to 
have a designated siteAdmin and we don't even have a single user for that
site 
so far.

Well, yes: The solution would be to add a couple of input fields to allow
you 
to create a designated siteAdmin from the same page, too.

On the backend it gets a bit complicated then:

What do we do if the siteAdmin has his siteAdmin flag removed later on? Or
if 
that user is suspended? We'd then need to remove the above php_flag from the

Apache vhost container of that site. Or we would need to check if there is 
another siteAdmin available for that site und use him instead. But if there
is 
more than one siteAdmin, then which one do we use in that case?

Next there is the transitional issue: Even if this is coded, what happens
when 
the updates are installed? Said php_flag is not set for existing VSites that

have PHP enabled. So we would need to run a constructor that checks all
sites 
if they have PHP enabled, need to check if the php_flag is already set and
if 
not, we need to pick an existing siteAdmin of that site an have to add that 
line to the vhost container of that site. I can imagine a few steps along
the 
way where this will not really work out the way we want it to.

This new addition would also need to survive CMU migrations. Generally it 
should do that just fine, but that also needs to be verified with some 
testing.

So yeah: This is possible, but all in all it'll be quite a bit tricky to
pull 
off.

On the up-side of things: With suPHP enabled we don't have that problem to 
begin with, as the email header already shows the username of the owner of
the 
script. Hence for suPHP enabled Vsites we don't really have to set him 
separately with that php_flag. In fact we must not set it in a php_flag for 
suPHP enabled sites, as the php_flags in the Vhost container are then
ignored 
anyway, as suPHP enabled Vsites have their own php.ini. For good measure we 
could also set it in the php.ini then, although that would be a bit
redundant.

All in all this new addition would only benefit "regular" PHP.

I'll play with the idea for a bit and will see if I can come up with 
something. But it's not hacked together in a day or two, as it requires 
changes on many levels in base-vsite, base-user, base-apache.

-- 
With best regards

Michael Stauber
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx