AMI Live Dangerously Override

[tsawyer]

It would be advantageous to allow app_rpt commands to work without enabling live_dangerously. Is it possible to override what conf files or commands are dangerous?

live_dangerously = yes          ; Enable the execution of 'dangerous' dialplan
                                ; functions and configuration file access from
                                ; external sources (AMI, etc.) These functions
                                ; (such as SHELL) are considered dangerous
                                ; because they can allow privilege escalation.
                                ; Configuration files are considered dangerous
                                ; if they exist outside of the Asterisk
                                ; configuration directory.

[InterLinked1]

What do you mean by allow app_rpt commands to work, specifically, from an Asterisk perspective?

I thought live_dangerously only applied to files outside of /etc/asterisk but I'm not positive. Could be something I can work out upstream.

[Allan-N]

I think what we are hoping for is to be able to use AMI's "UpdateConfiguration" for local (127.0.0.1) connections without needing to set "live_dangerously = yes". Certainly, allowing AMI connections over the wider internet would need one to live dangerously.

[tsawyer]

It talks about the changes to the dialplan as well so I assume it's not only a problem for files outside /etc/asterisk/.

[tsawyer]

able to use AMI's "UpdateConfiguration" for local (127.0.0.1) connections without needing to set "live_dangerously = yes"

Need it for remote AMI connections, too.

[Allan-N]

Hmmm... I just turned live_dangerously off and was still able to write a .conf file (in the /etc/asterisk directory). Maybe the error encountered earlier was trying to write outside of /etc/asterisk. Tim?

[tsawyer]

Possible... I'll follow up.

[tsawyer]

I was able to make a change to /etc/asterisk/rpt.conf locally thru the AMI with live_dangerously off.

Is writing outside of /etc/asterisk/ the only restriction of live_dangerously?

[InterLinked1]

I was able to make a change to /etc/asterisk/rpt.conf locally thru the AMI with live_dangerously off.

Is writing outside of /etc/asterisk/ the only restriction of live_dangerously?

No, but it's one of them. Is there anything else inhibited by it being off?

[tsawyer]

Its comments mentioned the dialplan. There is need to change extensions.conf.

[InterLinked1]

Its comments mentioned the dialplan. There is need to change extensions.conf.

Sorry... not sure I follow, can you elaborate?

[tsawyer]

You asked "Is there anything else inhibited by it being off?" Form reading the live_dangerously comments it looks like there will be if we do anything to the dialplan. We will need to make changes to extensions.conf. I'll let you know when I find out what breaks.

[InterLinked1]

You asked "Is there anything else inhibited by it being off?" Form reading the live_dangerously comments it looks like there will be if we do anything to the dialplan. We will need to make changes to extensions.conf. I'll let you know when I find out what breaks.

That's for editing the dialplan from AMI, or things like that. I don't think anyone is doing that, is that the case?

[tsawyer]

We do edit the dial plan for black/white lists. https://wiki.allstarlink.org/wiki/Blacklist_or_whitelist

Perhaps there is a better way to set this up such that only database entries need to be made.

[InterLinked1]

We do edit the dial plan for black/white lists. https://wiki.allstarlink.org/wiki/Blacklist_or_whitelist

Perhaps there is a better way to set this up such that only database entries need to be made.

There is. You can use the built-in BLACKLIST function for a simple blacklist.

For anything beyond that, you can store things in the AstDB database. That would be the "right" way to do that here.

[tsawyer]

Some prefer WHITELIST. Can we use the SQLite3 database? The keytree would be handy.

[InterLinked1]

Some prefer WHITELIST. Can we use the SQLite3 database? The keytree would be handy.

There is no builtin WHITELIST function. It's not really the type of "primitive" that Asterisk provides (and BLACKLIST in my opinion shouldn't exist as it is).

Yes, using the database is the way to go, you can store things there and then use the DB functions to interact with it. Then you can have your own custom logic in the dialplan to query the DB, add things to it, etc.

[tsawyer]

People like to limit connections to a few of their own nodes. It's not possible to blacklist all but a few nodes.

[InterLinked1]

People like to limit connections to a few of their own nodes. It's not possible to blacklist all but a few nodes.

I understand what you're saying. Whatever custom logic is desired to interact with the DB can be written in the dialplan. My comment is merely that there is no Asterisk built-in function to do what you want exactly out of the box.

On another note, are inbound calls verified in someone to ensure the node is really the node it claims to be? Otherwise, it seems like that would work around the issue you're trying to solve here.

[tsawyer]

Can we Slack huddle?

[InterLinked1]

I think this has long been resolved, so I'm closing this.