| Exec Security [message #178988] |
Sat, 01 September 2012 01:49  |
Ryan
Messages: 15
Registered: July 2012
Karma: 0
|
Junior Member |
|
|
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?
|
|
|
|
| Re: Exec Security [message #178990 is a reply to message #178988] |
Sat, 01 September 2012 02:12  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Exec Security [message #178991 is a reply to message #178988] |
Sat, 01 September 2012 06:54 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Exec Security [message #178992 is a reply to message #178988] |
Sat, 01 September 2012 09:51 |
Ryan
Messages: 15
Registered: July 2012
Karma: 0
|
Junior Member |
|
|
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.
|
|
|
|
| Re: Exec Security [message #178993 is a reply to message #178992] |
Sat, 01 September 2012 11:19 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Exec Security [message #178995 is a reply to message #178993] |
Sat, 01 September 2012 18:50 |
Ryan
Messages: 15
Registered: July 2012
Karma: 0
|
Junior Member |
|
|
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.
|
|
|
|
| Re: Exec Security [message #178996 is a reply to message #178995] |
Sat, 01 September 2012 20:19 |
Ryan
Messages: 15
Registered: July 2012
Karma: 0
|
Junior Member |
|
|
|
I was reading about something that will make this work. PHP-FPM pools, which can allow you to override configuration per vhost.
|
|
|
|
| Re: Exec Security [message #178997 is a reply to message #178996] |
Sat, 01 September 2012 20:26 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: Exec Security [message #178999 is a reply to message #178995] |
Sat, 01 September 2012 21:23 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Exec Security [message #179000 is a reply to message #178998] |
Sat, 01 September 2012 23:14 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Exec Security [message #179001 is a reply to message #179000] |
Sun, 02 September 2012 00:17 |
Ryan
Messages: 15
Registered: July 2012
Karma: 0
|
Junior Member |
|
|
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.
|
|
|
|
| Re: Exec Security [message #179002 is a reply to message #179001] |
Sun, 02 September 2012 07:25 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Exec Security [message #179003 is a reply to message #179002] |
Sun, 02 September 2012 11:02 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Exec Security [message #179005 is a reply to message #179002] |
Mon, 03 September 2012 03:32 |
Ryan
Messages: 15
Registered: July 2012
Karma: 0
|
Junior Member |
|
|
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.
|
|
|
|
| Re: Exec Security [message #179006 is a reply to message #179005] |
Mon, 03 September 2012 03:35 |
Ryan
Messages: 15
Registered: July 2012
Karma: 0
|
Junior Member |
|
|
|
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.
|
|
|
|
| Re: Exec Security [message #179008 is a reply to message #179006] |
Mon, 03 September 2012 03:43 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Exec Security [message #179009 is a reply to message #179008] |
Mon, 03 September 2012 03:53 |
Ryan
Messages: 15
Registered: July 2012
Karma: 0
|
Junior Member |
|
|
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.
|
|
|
|
| Re: Exec Security [message #179010 is a reply to message #179009] |
Mon, 03 September 2012 04:55 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]