[asterisk-dev] AstriDevCon - PineMango

[Tzafrir Cohen]

On Tue, Oct 14, 2008 at 02:27:50AM +0200, Tzafrir Cohen wrote:
> On Thu, Oct 09, 2008 at 09:16:52PM +0200, Tzafrir Cohen wrote:
> 
> > That is indeed a different problem. So now thing of a similar problem.
> > Your siwtchboard is connected to an Asterisk box (maybe several of
> > those) and serves several users. You want to allow different users to
> > control a different subset of extensions.
> > 
> > Is it possible to easily tell that an even is related to one of the
> > devices in the group "company_a"?
> > 
> > Or do we end up again without you getting the information you need for
> > your switchboard?
> 
> And now let's look at a slightly different problem. A shared hosting
> setup. Both company_a and company_b are hosted on that server. Each has
> its own skilled programmers that use the interface from
> PineMango-Asterisk to create their own custom programs.
> 
> Among those are custom programs that manipulate the dialplan. How can we
> guarantee that company_a and company_b don't edit each other's dialplan?
> 
> But then again, there are other nasty things company_a and company_b
> could do through the API to edit each other's dialplan. For instance, a
> series of System(sed -i <something> /etc/asterisk/extensions.conf)
> commands can be handy. 
> 
> So I suggest that System() is a priviliged command that should be
> blockable in a virtual hosting setup. 

Here are some ideas on encountering this issue. They do require
additions and changes of semantics. But so do any other proposed fixes.

Alice and Eve completely distrust each other. They do trust the
administrator. But we want to allow them as much liberty as possible
when managing their own parts of Asterisk.

In order to allow Eve to edit part of the dialplan, let Allice edit
other parts of the dialplan and not have the two of them worry about
each other, we first must tell what parts of the dialplan belong to each
of them:

[common]
; common parts of the dialplan. Can be used / included by anybody.

[al]
; This is the dialplan bit that Allice manages, and has full control of.
owner = allice

[eve]
; This is the dialplan bit the Eve manages and has full control of.
owner = eve


So what changes are needed in the semantics?
First off, a channel needs to have a defined ownership as well. The
processes that belong to Allice's virtual PBX need to be marked 
accordingly. Likewise the processes that belong in Eve's one. I
mentioned using some "read only variables". Olle has his own grand
scheme. There are surely ways to do that.

1. include => in extensions.conf
A user's contexts may only include contexts it is allowed to see. I
think that this could be enforced at dialplan generation time.

2. Goto/Macro/Gosub
Likewise whenever a channel goes to a different context, a channel of
Allice can go to a common context or one of Allice. But not to one of
Eve. Permission Denied. 

(or is it "Not Exists"? A different namespace? I have no idea how to
implement that. At first glance it seems more complicated).

3. Exec("Goto"), etc.
But there are many other ways to change a context. So we cannot enforce
it in the dialplan application level. Those contexts must be really not
available. 

Eve cannot tell that Allice hides her secret key in the dialplan. Allice 
must not be hit from the stupid bug Eve has in her dialplan.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir