[asterisk-dev] AstriDevCon - PineMango

[Tzafrir Cohen]

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
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir