Is there anything on the roadmap to add ACLs to ARI? ARI is incredibly powerful, if an attacker was able to access this interface it looks like they could:
Load and unload modules
Enable/disable logging
Snoop on and record calls
Access recordings
The following also appears to be true:
Only basic password protection is available
Only network facing TCP sockets are available (No UNIX sockets)
No mutual TLS support
No way to limit which APIs a user can call
From a security perspective this is pretty scary, I’m not comfortable enabling this on a production server. Are there any plans to add ACL support so that apps can be limited to only the APIs & resources they need?
No, that is not a solution because it still leaves the highly powerful and loosely protected ARI interface listening on a network socket. It’s obviously possible to limit access by binding to 127.0.0.1 and adding firewall rules, however for an interface this powerful it would be advantageous to limit what the API can do at the source, rather than rely on external controls which may be potentially bypassed.
I don’t want to have to put an external gate in front of the API, I want the API to be able to be configured into a safe configuration where I don’t need to.
I’m also not looking for stopgaps or workarounds, I know how to work around the issue. I want to know if it’s on the roadmap to add improved access controls to this very powerful API.
What happened to the fundamental Unix design principle of “do one thing and do it well”? ACLs should be handled by firewalls, not by telephony toolkits.
Yes, that is a solution, because you can use iptables/nftables to restrict access to that socket. Or stick the whole Asterisk process in a separate container.
As for “do one thing and do it well”, as Rob Pike has said, “Those days are dead and gone and the eulogy was delivered by Perl”.