[BlueOnyx:01474] YUM updates released (security update!)

[Michael Stauber]

Hi all,

The HTML version of this message is available here:

http://www.blueonyx.it/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=35&cntnt01origid=51&cntnt01returnid=54

Updates for BlueOnyx were released today are are now available through YUM. 

**** This is an important security update and you should install it ASAP. ****

==========
 Package  
==========

Updating:
 base-user-capstone
 base-user-glue
 base-user-locale-da_DK
 base-user-locale-de_DE
 base-user-locale-en
 base-user-locale-ja
 base-user-ui
 base-vsite-capstone
 base-vsite-glue
 base-vsite-locale-da_DK
 base-vsite-locale-de_DE
 base-vsite-locale-en
 base-vsite-locale-ja
 base-vsite-ui

Transaction Summary
============================
Install      0 Package(s)
Update      14 Package(s)
Remove       0 Package(s)


These package addresses the following issues:

base-user & base-vsite:
===================

Important security update: This update closes a vulnerability that allowed 
suspended users (or users of a suspended site) to still send emails using 
SMTP-Auth.

IMPORTANT: If you have any suspended sites or users on your server, please be 
sure to manually run this command from SSH as root:

/usr/sausalito/sbin/fix_user_suspension.pl

That will make sure that suspended users (or users of a suspended site) get 
deactivated in the underlying authentication mechanism.


Detailed explanation:
=================

This security vulnerability has been in the code since the RaQ550 - but it 
only surfaced when the feature SMTP-Auth was added to the (then) BlueQuartz 
code base.

If you suspended a user or a virtual site, then the GUI (so far) simply 
changed the permissions of that user home directory and/or virtual site so 
that these directories were no longer group readable. Or world readable in 
case of the webspace.

There was not that much wrong with this. Because back on the RaQ550 users 
could only relay email if their IP was in the allowed list of the Sendmail 
access configuration. Or if they used POP-before-SMTP.

If someone tried to FTP to such a disabled account or site, FTP would refuse 
to change into the diretcory as the user had no longer the rights to do so. If 
a suspended user tried to login to POP3 or IMAP, the modified permissions 
wouldn't let him in either.

POP-before-SMTP would register the generated failure message, too, and 
wouldn't allow that user to send emails. All fine so far.

However: When SMTP-Auth was added, users could now send emails by 
authenticating against the SMTP server with their username and password. Which 
is a much more relieable and less hack'ish solution than POP-before-SMTP. So 
for this a POP3 or IMAP login isn't needed prior to the start of the session.

BUT: As the user account had not been disabled on the system level user 
authentication (PAM or Shadow on BlueQuartz or Shadow only on BlueOnyx), 
suspended users (or users of suspended sites) can still login to SMTP-Auth 
against Sendmail and can therefore send emails.

That defenitely should not be the case, because suspending users (or sites) 
should prevent them from using any services that require authentication in 
first place.

So this update modifies base-user and base-vsite. Whenever a user is 
suspended, then that user will be disabled in the underlying system 
authentication layer.

Likewise: If a site is suspended, all users of that site will be disabled in 
the same fashion. This actively prevents disabled accounts from authenticating 
against any service that require a valid username and password on the server.


/usr/sausalito/sbin/fix_user_suspension.pl
=================================

That new script was added with this patch. You can run it (as root!) at any 
time, but you really only need it to run just once after the patch was 
installed and IF you have sites or users that currently ARE suspended.

When it is run, the script goes through all sites and all users. It 
synchronizes the suspension state of sites and users with the underlying 
authentication mechanism. So if a site is marked as suspended in the GUI, then 
the user accounts of all users of that site get "locked", preventing them from 
loggin in. Likewise, if just a user has been suspended (but the site itself 
has not), then only that user gets "locked".


CMU:
=====

The new "suspension" mechanism also carries over if you import sites or users 
through CMU. So if you import a site with suspended users (of if the imported 
site is suspended in general), then the new code will automatically already 
"lock" those accounts on cmuImport. Hence then there will be no need to run 
/usr/sausalito/sbin/fix_user_suspension.pl manually after a cmuImport. But it 
doesn't hurt either if you do.


/usr/sausalito/sbin/fix_user_UID_and_GID.pl
===================================

This newly added script has nothing to do with this security fix. If run as 
"root" it will go through all sites and users and will chown both the logfiles 
of the site and all user directories to the correct UID and GID that they 
should belong to. It will NOT change the UID or GID of the site's webspace (or 
any files therein).

The primary purpose of this script is to fix up garbled UID's and GID's that 
can sometimes happen if you import from a bad CMU dump.


-- 
With best regards

Michael Stauber