YUM updates (security update!)

Updates for BlueOnyx were released today and are now available through YUM. This is an important security update and you should install it ASAP.

The following updates for BlueOnyx were released today and are now available through YUM:

==========
 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.

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) could still authenticate against SMTP-Auth and then send emails through Sendmail.

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

So this update modifies base-user and base-vsite. Whenever a user is suspended, then that user will be disabled ("locked") 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 services that require a valid username and password to do anything 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 (or if the imported site is suspended in general), then the new code will automatically "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.