<div dir="ltr">Hi All,<br><br>&nbsp; I&#39;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">&lt;<a href="mailto:tzafrir.cohen@xorcom.com">tzafrir.cohen@xorcom.com</a>&gt;</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>

&gt;<br>
&gt; On 11 Oct 2008, at 18:54, Tzafrir Cohen wrote:<br>
&gt;<br>
&gt; &gt; On Sat, Oct 11, 2008 at 06:59:23PM +0200, Johansson Olle E wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; 9 okt 2008 kl. 18.28 skrev Russell Bryant:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; Brian Degenhardt wrote:<br>
&gt; &gt;&gt;&gt;&gt; This whole auth thing is a good idea. &nbsp;It&#39;s definitely worth<br>
&gt; &gt;&gt;&gt;&gt; keeping in<br>
&gt; &gt;&gt;&gt;&gt; mind. &nbsp;However, to demand that it MUST be implemented in our first<br>
&gt; &gt;&gt;&gt;&gt; stab<br>
&gt; &gt;&gt;&gt;&gt; at giving Asterisk a usable programming API risks bloating the<br>
&gt; &gt;&gt;&gt;&gt; scope of<br>
&gt; &gt;&gt;&gt;&gt; the project to the point that it would never get done.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; From someone more than likely to be heavily involved in figuring out<br>
&gt; &gt;&gt;&gt; how we would acquire the time and resources to make this happen ...<br>
&gt; &gt;&gt;&gt; +2 &nbsp;:)<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; If you create the architecture without this in mind from start, there<br>
&gt; &gt;&gt; will no resources<br>
&gt; &gt;&gt; available on earth to fix it afterwards. I think it&#39;s just plain<br>
&gt; &gt;&gt; naive<br>
&gt; &gt;&gt; to create<br>
&gt; &gt;&gt; an API on this level today without doing proper work on<br>
&gt; &gt;&gt; authorization.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; To solve it outside of Asterisk is also something that might be done,<br>
&gt; &gt;&gt; but then you disable it in Asterisk after you know that you can trust<br>
&gt; &gt;&gt; another model. But it should really &nbsp;be architectured within the<br>
&gt; &gt;&gt; core.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; A new framework should not be built with a notion of &quot;security -<br>
&gt; &gt;&gt; that&#39;s somebody else&#39;s problem!&quot;. For me, that&#39;s just bad.<br>
&gt; &gt;<br>
&gt; &gt; Let&#39;s look into a little example. One of the operations a control<br>
&gt; &gt; interface would allow is to originate the generation of another<br>
&gt; &gt; channel.<br>
&gt; &gt;<br>
&gt; &gt; How exactly would you allow a useful but limited channel origination<br>
&gt; &gt; action? What exactly is &quot;limited&quot;?<br>
&gt; &gt;<br>
&gt; &gt; Suppose I want I user to be able to originate calls from his phone.<br>
&gt; &gt; I do<br>
&gt; &gt; want to allow Joe to originate calls from SIP/Joe (or is it ZAP/12 ?).<br>
&gt; &gt; I don&#39;t want Jow to be able to originate calls from SIP/trunk/123456 .<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I want to be able to let some remote users connect through those<br>
&gt; &gt; interfaces. And we can&#39;t really trust remote users to play nice.<br>
&gt;<br>
&gt; No, you can&#39;t and we all agreed that, but the question is -<br>
&gt; which layer do you give remote users access to ?<br>
&gt;<br>
&gt; (see <a href="http://astridevcon.pbwiki.com/Codename+Pinemango" target="_blank">http://astridevcon.pbwiki.com/Codename+Pinemango</a> for the diagram)<br>
&gt;<br>
&gt; We don&#39;t give them direct access to the blue layer, or even the<br>
&gt; olive green one - but you could give them access to the orange ones<br>
&gt; (e.g. REST) - it would be the responsibility of the REST server<br>
&gt; to do suitable argument filtering and reject URI that were not<br>
&gt; 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&#39;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>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; How do you link such a remote user to some limitation on channels?<br>
&gt;<br>
&gt; That&#39;s a good illustration of why the security checking has to be<br>
&gt; done quite high up in the stack, where the difference between<br>
&gt; the channels has a meaning (in the core asterisk<br>
&gt; all SIP channels are equal)<br>
&gt;<br>
&gt; The proposal was that this sort of checking would be done in the<br>
&gt; second layer down - i.e. the Framework layer where the meanings<br>
&gt; of the users and trunks are known.<br>
&gt;<br>
&gt; Originate is (relatively) easy, as the command has to pass all the<br>
&gt; way down the stack, from the top to the bottom, so wherever we put<br>
&gt; 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>
&gt;<br>
&gt; SIP Transfer is messier, because it comes up from the bottom, and we<br>
&gt; need to provide a mechanism for the framework (or possibly the<br>
&gt; application)<br>
&gt; layer to reject a transfer. That&#39;s what hooks are supposed to do, they<br>
&gt; get added by a framework that wants finegrain control over actions<br>
&gt; that by default would just &#39;happen&#39; in the core layer. Notice that it<br>
&gt; isn&#39;t<br>
&gt; the core asterisk that makes the decision, it is the framework or<br>
&gt; 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>
&quot;user&quot; qualification and allow a remote user to only manipulate channels<br>
of his user? We&#39;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>
&gt;<br>
&gt; Just to be clear - I am not saying that we should just offer a totally<br>
&gt; open system to the whole world - I am saying that we should offer<br>
&gt; (as version 1) unrestricted access to all the _in_process components<br>
&gt; (the olive green layer).<br>
&gt;<br>
&gt; (As someone said - I forget who - if it is in the same memory space then<br>
&gt; any security you add in the calls can be bypassed by a rogue module<br>
&gt; that just directly fiddles with the bytes !)<br>
<br>
</div>I do trust (because I must) local modules. I don&#39;t trust remote users.<br>
<div class="Ih2E3d"><br>
&gt;<br>
&gt; The Yellow layer (in my _personal_ view) is more of a helper layer, I<br>
&gt; proposed a kerberos-like ticket system, where if you had a ticket for<br>
&gt; a channel or other core object then you can control it, but otherwise<br>
&gt; you can&#39;t, but it would have to be dynamic - because a PRI ZAP channel<br>
&gt; might be &#39;owned&#39; 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&#39;t) use?<br>
<div class="Ih2E3d"><br>
--<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Tzafrir Cohen<br>
icq#16849755 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:jabber%3Atzafrir.cohen@xorcom.com">jabber:tzafrir.cohen@xorcom.com</a><br>
+972-50-7952406 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 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> &nbsp;<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>
 &nbsp; <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>