Hello, After reading the documentation of asterisk : http://www.voip-info.org/wiki-Asterisk+non-root Normally asterisk shouldn't run as root. Could you please provide an ebuild to correct this security flaw. Thanxs in advance. Regards. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: asterisk run as root Expected Results: asterisk should run under asterisk group and user
It's ours
Indeed, I was waiting for the next ebuild to report it.
voip please advise.
This was planned for -1.0.8 (since i don't like making major changes between relases) but since it looks like there'll be no new upstream release anytime soon this will be -1.0.7-r1 will start working on this as soon as i have some spare time (probably thursday)
Thx Stefan.
asterisk-1.0.7-r1, zaptel-1.0.7-r1 and (only to make things complete) libpri-1.0.7-r1 are in the tree now (currently -* masked) *changes: - asterisk runs as asterisk:asterisk by default - permissions on /var/{lib,spool,run,log}/asterisk changed to asterisk:asterisk 750 / 640 /etc/asterisk changed to root:asterisk 750 / 640 - zaptel installs rules files for devfs and udev, changing permissions on device-nodes to root:dialout 660 - asterisk init & conf.d script changed use ASTERISK_USER to change the group / user asterisk runs as use ASTERISK_OPTS for additional options - bristuff updated to 0.2.0-RC8a (that's why libpri has been updated too) - pkg_config added to asterisk to fix permissions for users who have asterisk already installed *the init script uses start-stop-daemons --chuid instead of using asterisk's -U and -G option, reasons: - asterisk uses set(e)uid and set(e)gid to change user and group, making it impossible to use supplementary groups for the asterisk user - su requires a working shell to be set for the asterisk account (=bad) - start-stop-daemon uses initgroups, setting uid, gid and supplementary groups for the new process and doesn't have the requirements su has if you want asterisk to use zaptel devices, you can add asterisk to the dialout (supplementary, not primary) group using "usermod -G group asterisk" *todo & known issues atm: - todo: changes / warning message in asterisk ebuild - todo: message for pkg_config in asterisk ebuild - asterisk plugins need to change permission for files in /etc/asterisk - conflict between zaptel udev rules in zaptel and udev packages - devices like isdn*, capi* should probably belong to root:dialout instead of root:tty - modify default modules.conf in asterisk package to not load device dependant plugins (e.g. chan_oss, chan_alsa, chan_capi...) that's it for now comments? suggestions? questions?
Stefan does changing the permissions in src_install fix permissions for already installed packages? I believe you have to do it in pkg_postinstall as etc-update/dispatch-conf does not handle permissions well.
src_install cannot change permission in areas outside of ${D} and etc-update / dispatch-conf is for config files only messing with permissions in pkg_postinst is not a real good idea because a number of people might be using applications that require access to asterisk's data files (such as voicemail) that's why the stuff for new installs is in src_install and for already existing ones is in pkg_config i can change that... i hope people will actually read the warning messages at the top
Stefan valid point, what are the current permission on these files and do they contain any sensitive information (passwords etc.)? I guess some of the Asteriks config files are not read by any other apps.
Stefan any news on this one?
Stefan still no news on this one?
<stkn> both bugs, #96826 (stack overflow in asterisk manager interface) and #88732 (asterisk non-root) are fixed in -1.0.7-r1
asterisk-1.0.5-r2, -1.0.6-r1, -1.0.7-r1 and 1.0.8 have non-root support depending on the severity of the bugs fixed either -1.0.7-r1 or -1.0.8 will be a candidate for the next stable
Stefan are 1.0.8 or 1.0.7-r1 ready for arch testing?
stkn said that all versions except 0.9.0 have the security fixes. If we want to, we could test 1.0.7-r1, if any version at all goes stable, it's most likely this one.
x86/stefan please test and mark stable.
stkn marked this stable on x86
Thx Stefan*2 Since this is a defaul config bug -> closing with NO GLSA.
