[asterisk-dev] AstriDevCon - PineMango

[Tzafrir Cohen]

On Tue, Oct 14, 2008 at 03:45:23PM -0500, bkruse wrote:
> 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


I assume that when the a dialplan context is manipulated through the 
interface, the owner field is set (by the core).

> >
> >
> > 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.

I wasn't clear here. See clarification above. I do not consider this
application-level security.

> 
> > 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).

If you can edit extensions.conf directly? sure.

I asusme that only the administrator can do that.

Hence running 'System' may be a priviliged operation as well (allowed
only to channels of the administrator)

-- 
               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