The mailing list for listmasters using Sympa

[Peter Farmer <address@concealed>]

Redmond,

wwsympa isn't running as root - so you need to force the effective UID to 
root when it runs alias_manager.pl . Setting the setuid bit on the 
permissions for alias_manager.pl may work depending on your Apache set up, 
though this is not a good thing security wise. The other methods for 
executing alias_manager.pl via wwsympa.fcgi are similiar to those needed 
for executing wwsympa.fcgi itself - see section 9.2 of the Sympa manual. I 
would suggest you use the sudo method if you can. 

I havent tried this (I'm using postfix) so YMMV 8-) :

1. rename alias_manager.pl to unprivileged_alias_manager.pl (say)

2. create a script to replace /home/sympa/bin/alias_manager.pl 
   that executes unprivileged_alias_manager.pl via sudo as root e.g.

   sudo -u root /home/sympa/bin/unprivileged_alias_manager.pl $*

3. add an appropriate entry in /etc/sudoers to permit the sympa user 
   to run alias_manager.pl as root e.g.

sympa,apache  ALL=(root) 
NOPASSWD: /home/sympa/bin/unprivileged_alias_manager.pl

It would probably be nicer if we could specify the alias_manager command 
line in the configuration file, but its wired into the modules and scripts 
as the installed alias_manager.pl script.

If this all seems too complicated (and it probably is !) you might consider 
bypassing Sendmail security paranoia by using the "DontBlameSendmail" 
option (in the sendmail.cf file), and just giving group write access to the 
sympa or apache gids.   

To allow group write access to alias files (say by the sympa user ...) use a 
line like this:

0 DontBlameSendmail=GroupWritableAliasFile

To allow automatic creation of the alias file if it doesnt exist you'd also 
need to have group write access on the directory and add an extra 
argument :

0 DontBlameSendmail=GroupWritableAliasFile,GroupWritableDirPathSafe

I'd just manually create the file with sudo or root login and avoid the 
GroupWritableDirPathSafe option ...

The Sendmail authors don't recommend these security setting and neither do 
I, but if you know what your doing it is a possible option. Just dont blame 
me (or sendmail !) if it leads to a breach ...

Regards,
Peter Farmer

On Tuesday 06 June 2006 6:27 am, you wrote:
> Hello-
>
> I tried
>
> # chmod -R root:root /etc/mail
> # ls -la /etc/mail/
> total 384
> drwxr-xr-x   3 root root  4096 Jun  2 16:02 .
> drwxr-xr-x  82 root root 12288 Jun  5 16:40 ..
> -rw-r--r--   1 root root  9243 Jun  2 15:48 sympa_aliases
> -rw-r--r--   1 root root 24576 Jun  5 16:40 sympa_aliases.db
>
> It is still not automatically creating new aliases, but the sympa.log
> messages have changed /var/log/sympa.log
> Jun  5 17:10:45 announce wwsympa[3105]: [robot announce.uchicago.edu]
> [client 128.135.0.88] Could not find CSS file /style.css, using default
> CSS Jun  5 17:10:45 announce wwsympa[3105]: [robot announce.uchicago.edu]
> [client 128.135.0.88] [user address@concealed]
> do_create_list(06053,adsfdf,discussion_list) Jun  5 17:10:45 announce
> wwsympa[3105]: [robot announce.uchicago.edu] [client 128.135.0.88] [user
> address@concealed] do_create_list, get action : do_it Jun  5 17:10:45
> announce wwsympa[3105]:
> admin::check_topics(computing,announce.uchicago.edu) Jun  5 17:10:46
> announce wwsympa[3105]: admin::install_aliases : Unable to append to
> alias file Jun  5 17:10:48 announce wwsympa[3108]: WWSympa started
>
> Here are the permissions of executables in /home/sympa/bin, in case that
> makes a difference -rwxr-xr-x   1 sympa sympa   5971 Jun  2 14:12
> alias_manager.pl
> -rwsr-x---   1 root  sympa   6645 Jun  2 14:12 aliaswrapper
> -rwsr-sr-x   1 sympa sympa 466887 Jun  2 14:12 wwsympa.fcgi
> -rwxr-xr-x   1 sympa sympa     86 Jun  2 14:12 wwsympa_sudo_wrapper.pl
>
> Is there anything else I should check?
>
> Redmond
>
> +++ Peter Farmer <address@concealed> [06/06/05 10:20]:
> > Redmond,
> >
> > This is a common sendmail security issue - I found out the hard way a
> > long time ago 8-).
> >
> > The aliases file and its database files (generated by newaliases) must
> > be owned by root and writable only by root AND they must live in a
> > directory, every path component of which is owned by and writable only
> > by root.
> >
> > If database files are are not protected this way, attackers can create
> > private aliases files and then run 'sendmail -oA./aliases -bi' to
> > create a bogus database that can be copied over (or delete and replace)
> > the original.
> >
> > Regards,
> >
> > Peter Farmer
> >