asterisk dapper.2114_to_dapper.2234 diff

Jonas Smedegaard dr at jones.dk
Mon Aug 7 10:46:28 UTC 2006


On Mon, 7 Aug 2006 12:56:13 +0300 Diego Iastrubni wrote:

> On Monday 07 August 2006 12:16, Jonas Smedegaard wrote:
> > > -#chmod -R 0664 /etc/asterisk/
> > > +#chmod -R 0660 /etc/asterisk/
> > This one should certainly be enabled, I suspect!
> Does anyone needs to read this dir outside of the "asterisk" familiy?
> -> 660 IMHO 664 is enough, but who knows... 
> 
> I am commenting out the line with 660, lets see what breaks (don't
> forget also the subdirs like manager.d, extensions.d, etc):
> 
> chmod -R 0660 /etc/asterisk/
> find /etc/asterisk/ -type d | xargs chmod ug+rwx

I think we talk past each other here: You are worried if things break
due to too tight access rights. I am (here) worried about too loose
access rights!

Several configuration files may contain passwords, which should not be
shared with other users on the system (and expecially not www-data -
see below).


> > >  #find /etc/asterisk/ -type d | xargs chmod a+rx
> > > -#chmod +t /etc/asterisk/
> > > +#chmod g+s /etc/asterisk/
> > This looks odd to me. Both old and new command. Please elaborate.
> Yes.. I know... Tzafrir and me do not agree on how to solve this
> problem, but this is the main idea:
> 
> The creating of files inside this directory may come from the
> asterisk user, or www-data user. Sometimes by admin scripts running
> by "asterisk" user, and sometime by some web interface (which run as
> the user www-data, which is part of the asterisk group).
> 
> The sticky bit is my fix, Tzafrir fix is to patch the scripts to
> "chmod" the created files.

Arrgh - both approaches are wrong IMO!

Allowing www-data to read (and write!) asterisk config files
potentially means sharing passwords with the world!

Have a look at the horde3 package - even if upstream approach is to
have the configuration files generated through web, the Debian package
considers this too risky and requires the local admin to be in charge
of opening up (and hopefully cloing down again quickly afterwards) the
potential security hole.

Some local admins (like me :-) ) may choose instead to use SSL and a
chroot'ed httpd daemon which accesses the files as the asterisk user
but only after strong verification of the web-based user and encryption
of the communication. Or a simpler setup without encryption but
allowing access only from localhost (which is secure enough for some
setups, but not those with untrusted local users).


>  > $(CURDIR)/debian/tmp/usr/share/asterisk/firmware/iax
> >
> > Did you remember to invoke the script from asterisk postinst?
> >
> > And why provide as a separate script, if only relevant in the
> > asterisk postinst?
> No need to do this on the asterisk package, but on the
> asterisk-config package. The problem is that I want the same code to
> be run as part of the asterisk-config-freepbx package (which is on
> the svn, under the source code "freepbx", but still not been build).
> This package will be installed instead of asterisk-config:
> 
> apt-get install asterisk-config-freepbx asterisk
> 
> > I mean, if the purpose of the script is not only to correct mess
> > done by earlier packaging, but general fixup of whatever the local
> > user may mess about, then it is certainly too limited now ;-)
> not only earlier, but future packaging.

Packaging should include correct access rights. Relaxing and later
tightening is a bad approach!

Even if done once, I believe we should warn the local admin of the
bruteforce action: she may have hand-tuned access rights which are then
lost by the "fix". The above has already revealed a couple of possible
reasons to locally hand-tune access rights:

 * Fear of leaking passwords to third-parties

 * Need of tighter interaction with other applications


 - Jonas

-- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20060807/2bf209ba/attachment.pgp


More information about the Pkg-voip-maintainers mailing list