[asterisk-dev] AstriDevCon - PineMango

Sat Oct 11 21:33:10 CDT 2008

Hi All,

  I've updated the pbwiki with another diagram and my 2cents on the issue at
hand.

Nir S

On Sun, Oct 12, 2008 at 3:48 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com>wrote:

> On Sat, Oct 11, 2008 at 10:35:52PM +0100, Tim Panton wrote:
> >
> > On 11 Oct 2008, at 18:54, Tzafrir Cohen wrote:
> >
> > > On Sat, Oct 11, 2008 at 06:59:23PM +0200, Johansson Olle E wrote:
> > >>
> > >> 9 okt 2008 kl. 18.28 skrev Russell Bryant:
> > >>
> > >>> Brian Degenhardt wrote:
> > >>>> This whole auth thing is a good idea.  It's definitely worth
> > >>>> keeping in
> > >>>> mind.  However, to demand that it MUST be implemented in our first
> > >>>> stab
> > >>>> at giving Asterisk a usable programming API risks bloating the
> > >>>> scope of
> > >>>> the project to the point that it would never get done.
> > >>>
> > >>> From someone more than likely to be heavily involved in figuring out
> > >>> how we would acquire the time and resources to make this happen ...
> > >>> +2  :)
> > >>
> > >> If you create the architecture without this in mind from start, there
> > >> will no resources
> > >> available on earth to fix it afterwards. I think it's just plain
> > >> naive
> > >> to create
> > >> an API on this level today without doing proper work on
> > >> authorization.
> > >>
> > >> To solve it outside of Asterisk is also something that might be done,
> > >> but then you disable it in Asterisk after you know that you can trust
> > >> another model. But it should really  be architectured within the
> > >> core.
> > >>
> > >> A new framework should not be built with a notion of "security -
> > >> that's somebody else's problem!". For me, that's just bad.
> > >
> > > Let's look into a little example. One of the operations a control
> > > interface would allow is to originate the generation of another
> > > channel.
> > >
> > > How exactly would you allow a useful but limited channel origination
> > > action? What exactly is "limited"?
> > >
> > > Suppose I want I user to be able to originate calls from his phone.
> > > I do
> > > want to allow Joe to originate calls from SIP/Joe (or is it ZAP/12 ?).
> > > I don't want Jow to be able to originate calls from SIP/trunk/123456 .
> > >
> > >
> > > I want to be able to let some remote users connect through those
> > > interfaces. And we can't really trust remote users to play nice.
> >
> > No, you can't and we all agreed that, but the question is -
> > which layer do you give remote users access to ?
> >
> > (see http://astridevcon.pbwiki.com/Codename+Pinemango for the diagram)
> >
> > We don't give them direct access to the blue layer, or even the
> > olive green one - but you could give them access to the orange ones
> > (e.g. REST) - it would be the responsibility of the REST server
> > to do suitable argument filtering and reject URI that were not
> > acceptable.
>
> This suggests that authorization-based decisions are done at the point
> of the interface: when you get the command. But many aren't.
>
> Do you authorize a newly-generated channel to come into the dialplan? Do
> you authorize two channels to bridge together?
>
> So far the core does things through channels. A channel is the context
> in which many things are done. I suppose it will also include some sort
> of security credentials, inherited from the way it was generated.
>
> Hmmm... reminds me of SELinux.
>
> >
> > >
> > >
> > > How do you link such a remote user to some limitation on channels?
> >
> > That's a good illustration of why the security checking has to be
> > done quite high up in the stack, where the difference between
> > the channels has a meaning (in the core asterisk
> > all SIP channels are equal)
> >
> > The proposal was that this sort of checking would be done in the
> > second layer down - i.e. the Framework layer where the meanings
> > of the users and trunks are known.
> >
> > Originate is (relatively) easy, as the command has to pass all the
> > way down the stack, from the top to the bottom, so wherever we put
> > the security layer, the command will still pass through it.
>
> Originate requires that the remote user has the permissions to generate
> such a channel, and place it in that specific place in the dialplan.
>
> >
> > SIP Transfer is messier, because it comes up from the bottom, and we
> > need to provide a mechanism for the framework (or possibly the
> > application)
> > layer to reject a transfer. That's what hooks are supposed to do, they
> > get added by a framework that wants finegrain control over actions
> > that by default would just 'happen' in the core layer. Notice that it
> > isn't
> > the core asterisk that makes the decision, it is the framework or
> > application.
>
> A SIP Transfer requires that the remote user is authorised to manipulate
> all relevant channels. Is it enough to give each channels a sort of
> "user" qualification and allow a remote user to only manipulate channels
> of his user? We'll end up pretty fast with the need of too many things
> to be super-user. So this is probably not good enough.
>
> >
> > Just to be clear - I am not saying that we should just offer a totally
> > open system to the whole world - I am saying that we should offer
> > (as version 1) unrestricted access to all the _in_process components
> > (the olive green layer).
> >
> > (As someone said - I forget who - if it is in the same memory space then
> > any security you add in the calls can be bypassed by a rogue module
> > that just directly fiddles with the bytes !)
>
> I do trust (because I must) local modules. I don't trust remote users.
>
> >
> > The Yellow layer (in my _personal_ view) is more of a helper layer, I
> > proposed a kerberos-like ticket system, where if you had a ticket for
> > a channel or other core object then you can control it, but otherwise
> > you can't, but it would have to be dynamic - because a PRI ZAP channel
> > might be 'owned' by the owner of the DID (for an incoming call).
>
> How do we describe channels? How do we sanely describe all the channels
> a user can (or can't) use?
>
> --
>               Tzafrir Cohen
> icq#16849755              jabber:tzafrir.cohen at xorcom.com<jabber%3Atzafrir.cohen at xorcom.com>
> +972-50-7952406           mailto:tzafrir.cohen at xorcom.com
> http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20081012/ec42f331/attachment.htm 