[asterisk-dev] Permit/deny with negation patch

[Jonathan Rose]

Matthew Jordan wrote:
> From: "Matthew Jordan" <mjordan at digium.com>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Sent: Thursday, June 28, 2012 6:52:45 PM
> Subject: Re: [asterisk-dev] Permit/deny with negation patch
> 
> 
> 
> ----- Original Message -----
> > From: "Kevin P. Fleming" <kpfleming at digium.com>
> > To: asterisk-dev at lists.digium.com
> > Sent: Thursday, March 22, 2012 10:15:35 AM
> > Subject: Re: [asterisk-dev] Permit/deny with negation patch
> > 
> > On 03/20/2012 03:09 PM, Mark Murawski wrote:
> > > On 03/20/12 14:59, Tilghman Lesher wrote:
> > >> On Thu, Mar 8, 2012 at 11:11 AM, Tilghman
> > >> Lesher<tilghman at meg.abyt.es>
> > >> wrote:
> > >>> https://reviewboard.asterisk.org/r/1592/
> 
> <snip>
> 
> > >>> So in summary, is this a security fix? Or only a bug fix? Or
> > >>> just
> > >>> a
> > >>> new feature?
> > >>
> > >> So seeing no objection, we'll make this a security issue and
> > >> patch
> > >> 1.4, right? Bueller? Bueller?
> > >>
> > >> -Tilghman
> 
> <snip>
> 
> > > For me, I use permit/deny from a database but I have my data
> > > returned
> > > back in specific orders so I have expected results every time.
> > >
> > > I would call it a "new security feature", which... depending on
> > > how
> > > badly people want it, might make sense to put into 1.4.
> > >
> > > No doubt it will sure make writing the permit/deny rules much
> > > easier
> > > when configured from a db though.
> > 
> > My vote is to treat it as a security vulnerability of 'low'
> > severity
> > and
> > merge it into 1.4 and later release branches.
> > 
> 
> Resurrecting this discussion one more time...
> 
> We're at a good time to get this feature put into Asterisk, if
> everyone
> agrees that this can be viewed as a resolution to a low-risk security
> vulnerability.  If so, this feature will go into Asterisk 1.8+.
> 
> Otherwise, it can be committed to Asterisk trunk (11).
> 
> My inclination is to go with Kevin's suggestion at this point - does
> anyone
> have any objections?

My opinion is that this should go into 1.8, 10, and trunk. You could argue that it's not technically a bug, but it is definitely a partially implemented feature that I would say almost certainly doesn't work as intended (as much as the actual intent was probably overlooked) with realtime. Numerous documents about setting up realtime (for SIP peers for instance) are available which tell people to include permit/deny in their realtime database setups in spite of the fact that they aren't really useful as-is.

More importantly, the behavioral change won't have any impact on systems that are currently configured since it just adds new characters to separate and negate with. I don't see any likelihood for this patch to be at all disruptive.

Also the stuff I'm doing with named ACLs in Asterisk 11 will provide another work around for this anyway, so just putting it into Asterisk 11 has limited benefit.  I'd even go as far as to say using a comma separated list of named ACLs is a preferable way to handle this to using a permit field with multiple entries and inversion.

--
Jonathan R. Rose
Digium, Inc. | Software Engineer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
direct +1 256 428 6139 

Check us out at: http://digium.com & http://asterisk.org