Summary:	ASTERISK-08024: Disable shell escape '!' (bang) commands in cli
Reporter:	CJ Oster (lordvadr)	Labels:
Date Opened:	2006-10-29 10:48:35.000-0600	Date Closed:	2006-10-30 23:15:02.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/Configuration
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) noshell-cjo.patch ( 1) noshell-trunk-cjo.patch
Description:	Patch to add the ability to disable shell escape '!' (bang) commands both via command line and asterisk.conf config file. -- Changes -- Adds "noshell" config option to [options] portion of asterisk.conf.  Valid values are 1, on, true, and yes.  All othes are considered false (default). Adds -s command line argument to disable shell commands. If specified on command line, option is "on" regardless of contents of asterisk.conf. Prints "Shell commands disabled" via printf() to console if shell command is attempted. -- File Updates -- asterisk.c Add ast_config_AST_NO_SHELL global config variable (default 0) Add code to main() for command line option (-s) Add code to ast_readconfig() to process config file option Add code to consolehandler() for feature Add code to remoteconsolehandler() for feature asterisk.8 Update manpage to reflect new "-s" option doc/README.asterisk.conf Update documentation to reflect new option "noshell" -- Reasons -- I wanted PBX to boot with an asterisk cli interface already running on a virtual terminal.  I found out that even if asterisk is started under a different username and that user has no shell (/sbin/nologin for example), asterisk will still default to /bin/sh for shell commands. I realize that running an interface with no authentication probably isn't be best idea, but with physical security it has some advantages--mostly the ability for an administrator to instruct a non-administrator in the event of problems without having to give out passwords and the like. Giving the "asterisk" user a shell and password has so many other security vulnerabilities (ssh brute force, etc etc) that this was not seen as a valid solution. Incidentally, for anybody wanting to do the same, it requires the following, rather messy (but operational) line in /etc/inittab immediately under the section where all the mingetty's are started for your virtual terminals.  In this example, it runs on virtual terminal 7. 7:345:respawn:/usr/sbin/asterisk -rU asterisk </dev/tty7>/dev/tty7 2>&1 -CJO- ****** ADDITIONAL INFORMATION ****** Disclaimer is not on file _yet_ (no fax machine at home) but will follow.  Since the patch is so trivial, not sure if you even need, but disclaimer should be in by monday morning anyway. Patch for 1.4 tree coming soon (unless told otherwise).
Comments:	By: CJ Oster (lordvadr) 2006-10-29 11:40:33.000-0600 Disclaimer has been faxed in. By: Jason Parker (jparker) 2006-10-29 12:30:16.000-0600 New functionality isn't put into 1.2 or 1.4.  Could you upload a patch against svn trunk? By: CJ Oster (lordvadr) 2006-10-29 13:20:26.000-0600 You got it.  Although there isn't an equivalent README.asterisk.conf that I could find, so that's not included in the patch.  Feel free to delete the original patch. By: Olle Johansson (oej) 2006-10-29 13:41:12.000-0600 This is the annual repeat of a patch like this. It's been rejected every time before. Please mail the asterisk-dev mailing list to discuss, maybe you can get some support for it this time. By: CJ Oster (lordvadr) 2006-10-29 14:06:10.000-0600 Well, frankly, it makes no difference to me whatsoever whether it's included or not, I was just trying to contribute since some rather exhaustive googling returned nothing on the matter. It would also stand to reason that since similar patches have been submitted repeatedly, that there is at least _some_ demand for such a feature--and I'm not saying my patch is the best, just my $0.02 (and a rediculously trivial patch at that). Finally, and I'm going to say this tongue-in-cheek since while I've been programming and managing *nix systems for a very long time now, I'm sure many of you have been doing so much longer... It seems absolutely bizarre to me that an application would search for a shell when the account under which it's being run doesn't have one.  Both "more" and "less" have similar functionality (and I'm sure there are more, but only those two come to mind since those are the only ones I've ever used to... oh... BREAK INTO A MACHINE) for good reason.  Perhapse a ./configure option? Again, only my two cents.  Feel free to close the issue if you wish. Cheers By: Jason Parker (jparker) 2006-10-29 14:09:50.000-0600 Personally, I agree with the idea behind this patch.  Would somebody like to explain why similar patches have been shot down? This would be best discussed on the asterisk-dev mailing list though. By: Olle Johansson (oej) 2006-10-29 14:27:32.000-0600 Well, it would assume that the Asterisk CLI is secure enough to run like this, which it is not built for. It would be bad suggesting that people can run Asterisk -r as a Unix shell and rely on it. By: CJ Oster (lordvadr) 2006-10-29 14:51:13.000-0600 Perhapse that is something that should be addressed. Of course it all boils down to physical security, without which your dialplan is the least of your concearns.  Maybe a --tty option to grab a terminal which would prevent it being used as a remote login shell (which, as I understand, you can't pass options to a program via /etc/passwd anyway, or at least it's never worked for me and I haven't tried in quite some time).  But, and this is a BIG but, this might be huge for future embeded solutions. How about a CLI interface that is designed exactly for this purpose?  Authentication before allowing something that substantially modifies the running or on-disk config? I'd be happy to take on such a project if requested, but I agree with oej that the CLI simply wasn't designed for such a purpose. I apologize for submitting a repeatedly submitted patch.  Please close this issue.  I'll fire off something to the -dev list as soon as I get a chance. By: CJ Oster (lordvadr) 2006-10-29 18:50:48.000-0600 <vodka> Should someone post a patch that brings the asterisk CLI nearer to being "secure enough" to allow such functionality, will the same be rejected because no functionality exists that requires such security? I've seen a chicken lay an egg, but I've never seen an egg lay a chicken. </vodka> By: Olle Johansson (oej) 2006-10-30 02:07:38.000-0600 Well, we need to start with dividing the commands in various authorization groups, like what's done for manager (which is no good reference, but the only thing we have). Then when that's done, add a CLI login (optional) that puts the user in a CLI class. Let's say we group all "show/list" commands in one class and start with a command line option to only enable those commands, that would be a start. By: Tilghman Lesher (tilghman) 2006-10-30 23:12:54.000-0600 As has been said before: CLI> add extension 9999,1,System,"rm -rf /" into default This is even worse than the bang command, because the bang command only runs as the user connecting to the Asterisk process, not as the Asterisk process itself.  While the above is not as straightforward as a bang command, it is nevertheless possible to do far more harm to a system without using the bang command. And this is just off the top of my head.  I'm sure I could come up with more ways to do harm to an Asterisk system from the CLI, all without using the bang command.  This is NOT the security fix you're looking for.