[asterisk-dev] AstriDevCon - PineMango
bkruse at digium.com
Tue Oct 14 15:45:23 CDT 2008
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 parts of the dialplan. Can be used / included by anybody.
> ; This is the dialplan bit that Allice manages, and has full control of.
> owner = allice
> ; 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
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).
More information about the asterisk-dev