[asterisk-dev] AstriDevCon - PineMango

[bkruse]

Tzafrir Cohen wrote:
> 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. 
>
>   

Wouldn't this be an application level security?

We could flag the "owner" of each context (like mentioned with the 
config file), then when
a context switch happens (at the lowest level we can go, eg "does the 
context exist"), we can
see if the user has permission, if not, the context doesn't exist.

> 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.
>
>   
The bug situation. Is there ever a case in which I can make a boo-boo in
extensions.conf that hinders other parts of the dialplan from loading?
(eg other shared hosting users).

-bk