[asterisk-dev] AstriDevCon - PineMango

[Tim Panton]

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.

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

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.

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

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


Tim.