Rather than having the web server processes directly access the Asterisk console, you could have an intermediary privileged process that will perform very limited console functions (i.e. retrieve the needed information), and allow nonprivileged web frontend code to connect to this process and obtain the information.
Thanks – is there a standard method for privileging a process in this way? (This is Ubuntu 24.04.1) Or you mean the process would run as root and talk to the CGI process through a user-facing API?
If there was a mechanism to privilege a process rather than a user account to access certain commands/files (AppArmor?) then maybe I could just grant the CGI processes appropriately limited permissions and the www-data user could run them as it currently does but without the overly-broad sudoers permission? Just asking because it sounds easier than making an API for inter-process communication.
A carefully-designed API for interprocess communication is the only way to ensure the necessary degree of separation between the hostile outside world and your privileged back-end code.
Your information-gathering back-end server process runs as root, automatically started by a suitable service definition. It can open the Asterisk console API, since the Asterisk console socket is only accessible to root. On the other side, it listens on an internal port that your nonprivileged front-end code can connect to.
As for your front-end, don’t do CGI. There are more efficient alternatives. FastCGI seems to be obsolete now, but a common technique is to have your process be its own “mini” web server, sitting behind Apache or Nginx as the “real” web server, acting as a server-side proxy (aka “reverse proxy”), with both layers speaking HTTP. So the “real” web server takes care of heavy-duty stuff like virtual hosts and TLS/SSL encryption (and blocking certain kinds of—intentionally or otherwise—malformed requests), while your “mini” web server only needs to respond to the requests relevant to its function.
Another benefit is that these “real” web servers can tunnel WebSocket connections through to your “mini” server, for real-time two-way communication.
Hmm, ok, let me sketch out one implementation of what I think you’re describing and let me know if I got it right:
connect to front-end webserver over HTTPS, fetch a page like /dashboard
front-end webserver is configured to route that URL as a proxy to an internal webserver on a custom port, over HTTP
proxy webserver is implemented in python using an appropriate library, and is running as root
when handling the request, proxy webserver does what it needs to do to generate the HTML (connect to asterisk console, etc.) and responds
Is that about right? Or were you describing an additional layer, e.g. proxy webserver runs as www-data and connects over custom API to a privileged process?
Hmmm I have neither an asterisk user nor group. Is this an oversight on my part during installation? I just did the “make install” when installing, but didn’t set up a dedicated user.
On Monday 17 March 2025 at 21:38:05, chconnor via Asterisk Community wrote:
Hmmm I have neither an asterisk user nor group. Is this an oversight on my
part during installation? I just did the “make install” when installing,
but didn’t set up a dedicated user.
How did you install Asterisk, and under which distribution?
Some distros automatically configure the “asterisk” user, this might not be in
your case.
Antony
–
A reminder that “blacklisting” is not a racist term.
Installed via wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-22-current.tar.gz, did the install_prereq script, ./configure, make menuselect (mostly all defaults), make && make install, make basic-pbx, make config, make install-logrotate, then systemctl enable asterisk, and I went from there to configure.