[Asterisk-Security] Re: [Asterisk-Dev] Security of Asterisk shell out (Was: is this a bug?)

[C. Maj]

On Thu, 27 Jan 2005, Matt Riddell waxed:

> Aaron S. Joyner wrote:
> >  From a security-minded standpoint, is there a way to disable this 
> > functionality, either from the config file or startup arguments?  I 
> 
> This is a perfect example of a topic for the Asterisk-Security list.

This reply is cross posted there, so let's move discussion
off the -dev list.  I've been Ctrl-C'd to death !

> > don't personally think it's a good idea, but it's not beyond the realm 
> > of possibility that someone might consider providing the Asterisk CLI as 
> > a user's shell, in order to allow them limited administrative access.  A 
> > hypothetical example might be a manager or tech support representative 
> > being allowed CLI access to be able to execute "sip show peers", or the 
> 
> This sounds like a terrible idea.  That's like saying "I'll give the 
> manager root access on my box so he can check his email".

Asterisk has been my first jump into the PBX world, but from
researching alternate solutions, I've come to the conclusion
that there are varying levels of access to different PBXs.
Not all of them are root access on the CLI.

I've not used either of these, but interesting points none
the less:

http://www.ion-networks.com/voice_ip_pbxs.shtml

Check especially the last page of this doc which mentions 12
users and varying access levels:
(WARNING: PDF AHEAD)

http://www.teltronics.com/download/community/download/20030725_135051_20270.pdf

> Why not run my AstWinPeers program so that he can see the result of sip 
> show peers in a graph.

I agree this is an excellent domain for a GUI, but it
sidesteps the point.

> > like.  The ability to turn off direct access to a shell might be 
> > desirable, to limit their ability to easily affect the rest of the 
> > system, or at least require more complicated abuse to get shell-level 
> > access.
> 
> Dude, if someone's got full access to your console, (assuming you are 
> only running Asterisk on the box - as you should be) would mean that 
> they could kill the whole purpose for the box anyway.  Regardless of 
> whether or not the shell is present.
> 
> >... and even having such an option (to prevent shelling out) 
> > would potentially encourage bad security practices.
> 
> Quite the reverse I'd say.  I think if you thought it was safe to let 
> your manager or an outsider into your console, you'd do it.  We'd even 
> be better off allowing you to do as much as possible from the console so 
> as to prevent people from even considering letting anyone have access to it.

I'll vote no on that.  I think allowing for different
classes of users is a worthwhile security enhancement for
asterisk.  Even outside of PBXs, this idea is embraced for
CLIs.

PostgreSQL is a perfect example.  The database is always
running, just like Asterisk.  You should really have just
the database running on your machine, just like Asterisk.
PostgreSQL is installed by default under a non-root user,
which is where Asterisk needs to improve.  PostgreSQL allows
for the database super user to create different classes of
users, some of whom can then in turn create other users with
their same privilege level or less.

Using GUIs attached to the manager interface is a start,
since there is some limited ACL mechanisms for a few manager
commands.  But as far as the console goes, there is no such
concept that I am aware of.  It's still all or nothing.

I think it would be advantageous for larger installations to
allow someone to edit an extensions file for just their
department and reload only those extensions, possibly via
an #include file from the main extensions file.


-- 
Chris Maj, Rochester
cmaj_at_freedomcorpse_dot_com
Pronunciation Guide: Maj == May