Topic: send fax channel hangs after call completes [Comments: 8]
remiq
Wed, 07/28/2010 - 09:04 | send fax channel hangs after call completes
All faxes sent through the TL user web portal are not being hung up on asterisk. This is happening because TL is uploading the file to /tmp/ as root and the asterisk process is running under the asterisk user. Is there any way I can change the permissions on the uploaded file by TL?





Wed, 07/28/2010 - 16:38 | you might have an old
you might have an old version.. that was fixed a while ago i believe. You could always run asterisk as user 'root'.
Erik Smith
CTO
BluegrassNet Voice
dCAP
Thirdlane Support by BluegrassNet Voice
eeman at bluegrassnetvoice dot com
Wed, 07/28/2010 - 16:45 | I am not running an old
I am not running an old version, I am running PBX Manager 6.1.1.2.
Wed, 07/28/2010 - 17:30 | We don't run asterisk as root
We don't run asterisk as root for security reasons. We run it as user asterisk.
Wed, 07/28/2010 - 19:28 | that comment might mean
that comment might mean something if I thought for a second you knew what you were talking about =). You think getting root access via buffer overflow (not that there are any TCP sessions going on) is the biggest concern you have on a PBX???? The only shell user should be your administrators and you shouldnt have the console running on a virtual terminal. Exactly how secure is your AMI? Thats one of the biggest threats to your system. The security you need to concern yourself with have nothing to do with general unix security and have everything to do with people placing/receiving free phone calls off your box and getting you arrested for: wire fraud, aiding and abedding terrorism, theft by deception, credit card fraud, and spoofing callerid with intent to defraud.
asterisk loses certain features built in by not being able to run as root. Certain aspects of the IP stack are reserved to only root. Certain respawn features fail to also re-invoke because of its non-root status. The reason there was a push to run asterisk as non-root had less to do with security and everything to do with using Apache to configure FreePBX where apache cannot read/write to root owned files and Apache (being a TCP based service) IS a security risk running as root.
Erik Smith
CTO
BluegrassNet Voice
dCAP
Thirdlane Support by BluegrassNet Voice
eeman at bluegrassnetvoice dot com
Wed, 07/28/2010 - 19:59 | So official answer is that
So official answer is that Thirdlane does not support running asterisk as a non-root user?
Wed, 07/28/2010 - 20:20 | officially they do.. in fact
officially they do.. in fact they built the ISO's that way. Had they insisted on asterisk running as root there wouldn't be half the bugs like this that you have to deal with; root never has permission issues =). Digium and Asterisk.org still build their source tree to run as root. Changing the user is a feature and not one enabled by default. However, for now, there's no quick fix for you outside of running as root. I can't say for certain when that's going to get fixed, the non-root permissions was supposed to be fixed several versions ago with files in /var/spool/asterisk/fax.
personally I always run my machines with asterisk running as root. I did it for QoS packet markings and I do it because if there is a crash, safe_asterisk immediately respawns. Ive seen too many non-root designs where neither of those things worked right. Root owned processes also run at a higher nice level than non-root packages and under load are not the ones pushed to the side.
also forgot to mention the bit about root having a lot more open sockets and open file descriptors available than non-root users. This matters more on larger systems.
Erik Smith
CTO
BluegrassNet Voice
dCAP
Thirdlane Support by BluegrassNet Voice
eeman at bluegrassnetvoice dot com
Thu, 07/29/2010 - 22:40 | I reviewed the security
I reviewed the security advisories for Asterisk over the last 3 years and I must admit you are almost right;) 2 out of the 55 were Exploitable Stack Buffer Overflows.
http://downloads.asterisk.org/pub/security/ASA-2007-010.html
http://downloads.asterisk.org/pub/security/AST-2007-014.html
The large majority of the advisories were either unauthorized access to system or denial of service.
Thu, 07/29/2010 - 23:06 | and thats code
and thats code vulnerability... theres still brute force access attempts that go on every day. Its not a code exploit, its like trying to dictionary attack an FTP server. Theres another huge security hole with the AMI. Its a plain text socket connection with authentication. If you authenticate and someone sniffs those packets they too can authenticate through your AMI. Once autheticated they can start sucking down dialplan and originating calls from a remote IP (ex SIP/exten@1.2.3.4 which is your remote softphone) back through the dialplan of an existing tenant.
Erik Smith
CTO
BluegrassNet Voice
dCAP
Thirdlane Support by BluegrassNet Voice
eeman at bluegrassnetvoice dot com