As you may know, the cli module parlays raw user input from the FreePBX Administrator Control Panel (ACP) GUI back in to Asterisk via the Asterisk Manager Interface (AMI). This is an extremely powerful feature. So of course it is a target of some security analysts and wayward attackers – think of System, Originate, and the like.
We are considering some (potentially) breaking changes in this area of the GUI:
Do nothing.
Limit Asterisk commands/apps/functions with an allowlist.
Allow all the things except some specifically denied with a denylist e.g. very powerful commands/apps/functions.
Note that none of these changes would limit what you can do directly on the Asterisk CLI when connecting over local login/SSH sessions. That remains exclusively an area of concern between you and your keyboard
For anyone who understands security and how this all works you would know anything like this is simple theater at best or a gross statement that you don’t understand how any of this works.
NEVER RUN ASTERISK AS ROOT this solves almost all issues that need to be resolved
Single responsibility: Don’t put anything accept FreePBX on the FreePBX server. The Apache user (asterisk) has abnormal access but that is okay because you shouldn’t have anything else on this server.
Apache and the asterisk user will always need a certain level of functionality that can be accessed by anyone who can install a module. Breaking the cli app for “faux security” does nothing but break the cli app. I believe is already does filter out some things in case an idiot is running Asterisk as root.
tl;dr Take a look, it’s in a book, reading rainbow. Understand how things work before you touch them.
Well, almost all is debatable – better nowadays might be many.
Great! (accept vs except notwithstanding)
Not sure if we can fix that in time for v18 beta… long-standing issue, deeply architectural, etc.
So you agree those are (or should be) two separate accounts on the system ?
That is not a commandment, only a custom. Some modules make dialplan, some don’t. And some dialplan commands are more powerful than others. PBX operators can have guardrails and still get things done.
If you are the smartest person in the room, you are in the wrong room. People smarter and wiser than both of us have worked through much of this.
There are massive architectural flaws in FreePBX that stem from neglect and technical debt inherent to a project of this age. Much of it predates you. Large, sweeping changes are needed, and historically the people in charge of the purse will not pay for them. The alternative is community contribution. Unfortunately, much of that community has been treated poorly and they do not care to contribute. You need to engage the community rather than fight it, then maybe some of the free labor will show up.
If you want my opinion, I would put time and effort into moving all database operations to the Illuminate Database component rather than relying on raw SQL abstractions or generic ORM wrappers. This migration would allow auditing, rollbacks, and a whole mess of other capabilities. Along with this, I would start using something like Psalm and fix the countless type issues that are everywhere. You will never get the funding for either, but it would have the biggest impact on reducing bugs and modernizing FreePBX.
that does look productive, thank you.