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