Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #6917 > unrolled thread

Exec Security

Back to article view | Back to comp.lang.php

Contents

  Exec Security Ryan <rbilesky@gmail.com> - 2012-08-31 18:49 -0700
    Re: Exec Security Jerry Stuckle <jstucklex@attglobal.net> - 2012-08-31 22:12 -0400
    Re: Exec Security "J.O. Aho" <user@example.net> - 2012-09-01 08:54 +0200
    Re: Exec Security Ryan <rbilesky@gmail.com> - 2012-09-01 02:51 -0700
      Re: Exec Security "J.O. Aho" <user@example.net> - 2012-09-01 13:19 +0200
        Re: Exec Security Ryan <rbilesky@gmail.com> - 2012-09-01 11:50 -0700
          Re: Exec Security Ryan <rbilesky@gmail.com> - 2012-09-01 13:19 -0700
            Re: Exec Security Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-01 16:26 -0400
              Re: Exec Security Ryan <rbilesky@gmail.com> - 2012-09-01 14:11 -0700
                Re: Exec Security Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-01 19:14 -0400
                  Re: Exec Security Ryan <rbilesky@gmail.com> - 2012-09-01 17:17 -0700
                    Re: Exec Security "J.O. Aho" <user@example.net> - 2012-09-02 09:25 +0200
                      Re: Exec Security The Natural Philosopher <tnp@invalid.invalid> - 2012-09-02 12:02 +0100
                      Re: Exec Security Ryan <rbilesky@gmail.com> - 2012-09-02 20:32 -0700
                        Re: Exec Security Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-02 23:43 -0400
                          Re: Exec Security Ryan <rbilesky@gmail.com> - 2012-09-02 20:53 -0700
                            Re: Exec Security "J.O. Aho" <user@example.net> - 2012-09-03 06:55 +0200
          Re: Exec Security "J.O. Aho" <user@example.net> - 2012-09-01 23:23 +0200

#6917 — Exec Security

I am working on a PHP script that will create Nginx vhosts. Creating the files should be simple enough. The hard part is this command "service nginx reload" to load the new vhost config.

The result is I have to use Exec() to run the command.  The bad problem I host sites for clients on the server, they obviously should not have access to Exec().

Is there anything I can do to allow me to use it but prevent my other users?

[toc] | [next] | [standalone]

#6919

On 8/31/2012 9:49 PM, Ryan wrote:
> I am working on a PHP script that will create Nginx vhosts. Creating the files should be simple enough. The hard part is this command "service nginx reload" to load the new vhost config.
>
> The result is I have to use Exec() to run the command.  The bad problem I host sites for clients on the server, they obviously should not have access to Exec().
>
> Is there anything I can do to allow me to use it but prevent my other users?
>

I'm not at all familiar with Nginx, so I'll phrase this in Apache terms 
and maybe you can get the idea.

To PHP, there's no difference between users if you're running PHP as a 
module.  If you're running it as a CGI, you have more flexibility and 
should be able to specify a different php.ini file for each site (I 
haven't actually tried that, though).

You should also be able exec() in your <Virtual Host> entry for each 
host except yourself, but again I haven't tried this.

Maybe the easiest way to do this is to run a private server (one which 
requires a login to do anything) on a different port and use your own 
php.ini in that server.



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6920

On 01/09/12 03:49, Ryan wrote:
> I am working on a PHP script that will create Nginx vhosts. Creating the files should be simple enough. The hard part is this command "service nginx reload" to load the new vhost config.
>
> The result is I have to use Exec() to run the command.  The bad problem I host sites for clients on the server, they obviously should not have access to Exec().
>
> Is there anything I can do to allow me to use it but prevent my other users?
>

You could make a database table in which you store command to execute 
(use a id, not the command it self, like id 1 = reload nginx rules), 
time stamp when inserted and time stamp when executed.

Your php script will just add a line to the table.

You have another job which reads the table say every minute and takes 
all unexecuted and execute those (write some logic that makes it will 
only restart once if there is more than one request for reload/restart 
in the list at one time), as this one will run as a privileged user, it 
will not have issues with the commands.


This method is scalable to work with multiple servers if you have a 
centralized database server, in that case you need to add column for 
which host is supposed to execute the command. Worked fine when I workd 
at a hosting company.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#6921

That might just work to have a separate php.ini I might have to spin up a test server and try that out. 

Having a DB queue that is processed by a cron job is kind of a last resort. It would have to almost constantly be running or would have to wait too long to provision new vhosts.

[toc] | [prev] | [next] | [standalone]

#6922

On 01/09/12 11:51, Ryan wrote:
> That might just work to have a separate php.ini I might have to spin up a test server and try that out.

You can have different php.ini, but still it's possible for someone to 
use that to do something else than you intended.


> Having a DB queue that is processed by a cron job is kind of a last resort.
> It would have to almost constantly be running or would have to wait too long to provision new vhosts.

If you don't want to use cron jobs, then set up a service (you can write 
daemons with PHP) and use a message queue like zeromq, so the web 
interface sends a message to the daemon.

Using the database is a simple way to do it, when you want to expand, 
you don't want to do the plesk way where you need to setup everything on 
every server which is used for hosting, you want a one place to 
administrate things from.


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#6924

Can you please eplain what you mean about the per site pho.ink being misused?

A daemon is a waste at resources IMO since its always running though most of the time it will do nothing.

How do CPs handle this? I don't want to install a CP just replicate this functionality that will run only as needed.

[toc] | [prev] | [next] | [standalone]

#6925

I was reading about something that will make this work. PHP-FPM pools, which can allow you to override configuration per vhost.

[toc] | [prev] | [next] | [standalone]

#6926

On 9/1/2012 4:19 PM, Ryan wrote:
> I was reading about something that will make this work. PHP-FPM pools, which can allow you to override configuration per vhost.
>

This requires you to run PHP as a CGI instead of a module like most 
sites (see my first post).  Nothing necessarily wrong with it, other 
than a bit of extra processing for each page.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6927

I was under the impression that's what PHP-FPM was, pho ran as cgi. Is that not accurate.

[toc] | [prev] | [next] | [standalone]

#6929

On 9/1/2012 5:11 PM, Ryan wrote:
> I was under the impression that's what PHP-FPM was, pho ran as cgi. Is that not accurate.
>

No, I just mentioned running PHP as a CGI in my first reply to you.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6930

Afaik nginx only supports cgi not module for php is what I meant.

The daemon idea sounds interesting but seems a waste to always be runing in the backgound when nothing needs processed.

[toc] | [prev] | [next] | [standalone]

#6931

Ryan wrote:

> The daemon idea sounds interesting but seems a waste to always be runing in the backgound when nothing needs processed.

I doubt you are using something less powerful than my Nokia N900 and even on 
the N900 you won't notice a daemon which does idle most of it's life.

Go for security, it's not a X-Windows you will have running which would waist 
RAM and CPU on a server.

-- 

   //Aho

[toc] | [prev] | [next] | [standalone]

#6932

J.O. Aho wrote:
> Ryan wrote:
> 
>> The daemon idea sounds interesting but seems a waste to always be 
>> runing in the backgound when nothing needs processed.
> 
> I doubt you are using something less powerful than my Nokia N900 and 
> even on the N900 you won't notice a daemon which does idle most of it's 
> life.
> 
> Go for security, it's not a X-Windows you will have running which would 
> waist RAM and CPU on a server.
> 

The general way a daemon comes into play at the OS level - at least on 
*nix systems - is that  the multi-tasking scheduler scans all the 
sleeping processes and if nothing has happened to wake them up, skips 
them. This is at most a few machine cycle per process.

What is consumed is memory, virtual or otherwise.
Even the wake up process is relatively efficient. Ignoring paging memory 
in or out of swap space, all that happens is that the current processor 
state is stored in a special area, and the sleeping task context 
restored from kernel memory. The task then resumes from where it left 
off. If its memory space is paged out, then another daemon will be 
awoken to page it in.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6934

On Sunday, September 2, 2012 12:25:40 AM UTC-7, J.O. Aho wrote:
> Ryan wrote:
> 
> 
> 
> > The daemon idea sounds interesting but seems a waste to always be runing in the backgound when nothing needs processed.
> 
> 
> 
> I doubt you are using something less powerful than my Nokia N900 and even on 
> 
> the N900 you won't notice a daemon which does idle most of it's life.
> 
> 
> 
> Go for security, it's not a X-Windows you will have running which would waist 
> 
> RAM and CPU on a server.
> 
> 
> 
> -- 
> 
> 
> 
>    //Aho

Its not like exec() would just be enable for everyone therefore its not any less secure. But it becomes ALOT easier to not deal with a daemon reguardless of how little ram or other resources it would use.

[toc] | [prev] | [next] | [standalone]

#6936

On 9/2/2012 11:35 PM, Ryan wrote:
> Not to mention all the overhead of reading from a DB every 5 seconds to see if anything needs processed. I am not trying to DOS my DB.
>

Yes, TNP has no idea how the real world works.  He's very good at 
quoting things, but not so much at understanding them.

If you use a cron job with a database you'll have to check on every 
wakeup.  Not a tremendous overhead, but a lot more than TNP thinks.  And 
if the database is remote, the overhead is even more significant.

Alternatively you could use a daemon which monitors a UNIX (or TCP/IP) 
socket and send it a message when you need to do something.  That 
wouldn't have a lot of overhead.

But since you need to use CGI anyway, you might as well just enable 
exec() via a php.ini that only you use.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6937

That was my thinking, just glad someone can confirm it.

IMO I see no security issue with exec() in this setup. Its enabled only on my vhost, no client code can touch it. The command in exec() is hardcoded, not using any user inputs. Someone would have to find a way to write their own php script to use exec() and get it uploaded into my vhost to cause any problems. If they can manage to do that that can cause enough issues even with exec() disabled.

Glad I can get confirmation of this.

[toc] | [prev] | [next] | [standalone]

#6938

Ryan wrote:

> IMO I see no security issue with exec() in this setup. The command in exec() is hardcoded, not using any user inputs.
> Someone would have to find a way to write their own php script to use exec() and get it uploaded into my vhost to cause any problems.
> If they can manage to do that that can cause enough issues even with exec() disabled.

I have seen quite many times when a host with exec enabled and user code don't 
have any exec calls, where a someone managed to use trigger eval and then 
executed exec. I see both exec (and similar) and eval as no no in a web 
server. There will always come a day when you want to add something more and 
suddenly you have something that will allow things to go wrong, I think it's 
better to do a more solid solution from start, even if it takes more work, no 
matter if you do use a database or a message queue.

But it's your system, so you decide how you want to do things.


-- 

   //Aho

[toc] | [prev] | [next] | [standalone]

#6928

On 01/09/12 20:50, Ryan wrote:
> Can you please eplain what you mean about the per site pho.ink being misused?

If you allow a instance have access to exec from which you allow service 
be restarted (either full root access or sudo), then there is always a 
risk that someone can manage to execute something you thought was 
possible, this could lead to the whole machine is compromised.


> A daemon is a waste at resources IMO since its always running though most of the time it will do nothing.

Daemon ain't a waste of resources if you do it the right way, let it 
idle till it gets a message, it will make a small memory imprint, it 
will not waist many cpu cycles while not doing anything and you increase 
the security of your system.


I have seen a database based solution running on quite many servers, 
including web servers, database servers, dns and mail server been handle 
this way, the resources used by the provisioning software was quite 
small, would go as far as say it's not measurable.


-- 

  //Aho

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web