[asterisk-dev] AstriDevCon - PineMango

[Tzafrir Cohen]

On Mon, Oct 13, 2008 at 11:11:39AM +0200, Kevin P. Fleming wrote:
> Johansson Olle E wrote:
> 
> > And how do the SIP channel know who's allowed to do what?
> > It all comes down to the core anyway. The SIP channel will hopefully
> > move towards a more domain based segmentation. I need a way
> > to find out who's allowed to touch which sip channels, subscriptions,
> > transfers etc.
> 
> Well, this is really not possible. We've had this discussion many times
> before, in different contexts, but in essence, it boils down to
> mechanism vs. policy. In Asterisk, we're trying (at least with all new
> development) to never define *how* someone would use (or be able to use)
> a mechanism that we build, just provide the mechanism itself and let the
> imaginative users find out how it can be used.

If we stick with the metaphore of the operating system, there are some
things only the core can enforce. That does not mean the core should
decide on policy.

> 
> When it comes to issues like authentication and authorization, we could
> attempt to build a 'rules engine' inside the modules that have to
> implement the results of the AA checks, but defining such a rules engine
> will be very hard, and inevitably (and I mean within six months),
> application developers will tell us that our rules engine doesn't
> provide the sort of rules that they need. In that case, are we better
> off to continue extending the rules engine with more and more complex
> rules, or are we better off to just push the rules out of the core
> completely and let the application framework/developer define the rules
> and let us know whether a particular operation should be allowed,
> disallowed or limited in some way?

Each channel already has a "context" of some sort. A channel that was
originated by some interface should be allowed to do what the interface
user is allowed to do.

A channel driver should then become another sort of user. It originates
channels as well.

So authentication belongs in the edges. Authorization: in the core.

Right now we only deal with those with a dialplan context and setting of
variables. The trouble is that any channel can set variables to any
other channel. 

So how far can we go with the simple form of several channel-specific
variables that other channels can't set and that must be set on
origination time.

Who should be allowed to set them?

What should happen to them on bridging?


Where does such a concept break?

> 
> It certainly seems that the general consensus in this thread is that the
> latter is preferable, and I'm in agreement there. Even if we do end up
> building AA-related functionality in Asterisk, I don't think it will be
> in the API calls themselves, but parallel to the API, and associated
> with the API 'session' and any objects created or managed by the session.
> 
> > How can we enforce segmentation throughout the core, so that we can
> > allow everything from javascript voicemail check clients to adhersion  
> > frameworks to access
> > the core without colliding and only accessing what they're allowed to
> > access? Even if you guys write a wonderful framework that you think
> > solves all issues, someone will add another plugin on top of the
> > same pbx.
> 
> Or they'll write a C module that breaks the rules and convince the same
> system administrator to install it. At some point, we have to just defer
> responsibility to the administrator of the system involved. If they
> allow uncontrolled access to the internals of the system, then they'll
> be exposed to that sort of problem.

That's the equivalent to writing a kernel module that bypasses security
limitations. Most people won't do that. If many people will, it will be
a good sign that something is wrong with the design and we'll have to
revise it.

But under normal circumstances this is called "using root to get root".

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