[sr-dev] DMQ security

[Olle E. Johansson]

On 31 Oct 2013, at 12:20, Alex Hermann <alex at speakup.nl> wrote:

> On Thursday 31 October 2013, Charles Chance wrote:
>> On 31 Oct 2013 08:53, "Alex Hermann" <alex at speakup.nl> wrote:
>>> If not, then, imho, the admin already has plenty of possibilities
>> 
>> (IP-based,
>> 
>>> digest, TLS cert) to do authentication before calling that function.
>>> Why force one method if we can just leave it up to the admin to choose
>>> whatever fits best in his situation.
>> 
>> But aren't we allowing the admin to potentially shoot themselves in the
>> foot, as Olle puts it?
> 
> Of course, but there are plenty ways to shoot oneself. Kamailio is not an end-
> user application. I see it more like a compiler than a word-processor. Certain 
> capabilities are required to make an application with it.
Agree that it's not an end-user application. But as we see in Asterisk the admin
is changing away from the Unix and TCP/IP network specialist. I have students
in Kamailio classes that doesn't understand how to edit config files. That did not
happen three years ago. They all knew more about LInux than me then.

This should affect how we package and deliver our product.
> 
> I prefer the freedom to choose whatever method fits best in my 
> situation/application. I like the current way in which the admin decides how 
> INVITE, PUBLISH, XMLRPC, DMQ, etc are authenticated and/or authorized. None of 
> the (C-)code handling those methods need special authentication routines 
> implemented, it can all be done from within the script.
I never wanted to stop freedom to choose. But I no longer wanted the default to be
"oh, and if you want to secure it go ahead and do it yourself". 
We need to start thinking security by default.

> 
> Implementing additional authorization methods inside DMQ will limit choice and 
> create a higher burden on maintenance of the module.
I don't think so as long as we don't disable all the rest.


/O