[Savannah-hackers] Re: Mailing lists support at Savannah

[Sylvain Beucler]

Hi,

On Tue, Oct 26, 2004 at 05:56:46PM -0400, James E. Blair wrote:
> > Hi,
> >
> > We are planning to add the basic Mailman support in Savannah. There is
> > a recent script in Savane called "sv_mailman" that does the job
> > locally.
> 
> I've discussed this with others here at the office and we don't think
> this is the best approach.
> 
> When we rebuilt savannah we audited all of the Perl scripts and
> improved the coding conventions used in those scripts to make them
> more secure.  They were written with a number of flaws that could be
> exploited by attackers to gain local access.  sv_mailman does not
> incorporate the kind of security-conscious coding that we would like
> to see running on savannah.

As far as we could see, the changes in 3 files from the (formerly)
/usr/local/savannah/bin consist of changing the locking method,
deleting the environnement (which is cron's), and using some system()
instead of `` that contains no user-defined variables except the one
from root-owned savannah.conf.pl.

More extensive changes were made to sv_groups and sv_users so as to
support the new features such as per-project root, not
security-related.

We could not find the flaws allowing to gain local access.


> Further, some of the improvements we have made to other system
> scripts seem to have been reverted.

Did you check in /usr/savannah? Elfyn, when bugfixing the backend,
installed unmodifed files from Savane in the standard paths, while
setting the used files in the other hierarchy. sv_users and sv_groups
- the only script that we use actually for now are still modified
versions of the one you worked on. This configuration, abeilt
temporary, is documented. So no change was effectively reverted.


> I'm not talking about functional changes -- obviously all the
> savannah hackers have done a lot of work to bring the system back to
> a usable state -- but rather changes in programming that have an
> adverse impact on security.
> 
> If you would like, we can re-audit the savannah backend and point out
> the problems and solutions, as well as guide you in more
> security-conscious programming for the types of things that the
> savannah backend scripts are doing.

A post at address@hidden regarding the flaws in the current
backend will be much appreciated and productive :)


> When we made the new Associate Membership system, we had a similar
> problem, in that agia.fsf.org needs to manage a mailing list on
> lists.gnu.org.  We designed a system similar to the way we do
> savannah web checkouts on www.gnu.org, and we designed it with
> savannah in mind.
> 
> We considered doing remote mysql reads as you suggested, but we don't
> want to expose mysql to the network.  A compromise of savannah's
> database would be as bad as a compromise of the whole system.  Instead
> you can create a list and update its membership by hitting URLs on the
> web server on lists.gnu.org.  It's currently restricted to agia by IP,
> but we can add savannah when you're ready.
> 
> You can read about how to use it at:
> 
> lists.gnu.org:/home/list/README.update.py
> 
> You might be able to copy the code we use for www.gnu.org and adapt it
> for use in sv_mailman.  We could also do that work instead if you
> want.

If I understood well, running an in-house script restricted by IP
requiring using Savane in a non-standard way is more secure than
setting up a few stable components with SSL (in addition to firewall
and password) based authentication. We disagree with that.

Moreover, whenever somebody work on something that is indented to run
on Savannah, sending a mail to the Savannah hackers wouldn't hurt and
be nice.

-- 
Sylvain