Ein Test mittels “quotaoff /” und “quotaon /” sagten, dass alles in Ordnung sei. Der Test mittels “quotaon -p -u /” lieferte das gewünschte Ergebnis:

user-Quota auf / (/dev/###) ist an

Selbst manuelles setzen der quotas führte zum Erfolg und das quota war aktiv.

Nun was war das Problem mit Confixx?

Letztendlich kamen wir auf die Lösung: Confixx prüft nicht etwa den Rückgabewert von quotaon -p -u / sondern erwartet den String “on”, sprich die englische Variante.

ein “unset LANG” und ein erneutes “quotaon -p -u /” brachten nun das on zu Tage:

user quota on / (/dev/###) is on

Ruft man nun die admin.pl mit nicht gesetzter locale auf kann quota auch direkt aktiviert werden.

Ist es nicht schön wenn Software plötzlich neue Dinge kann?

Ein Aufruf über telnet der entsprechenden Website lieferte mir immer das richtige Ergebnis, aber weder ein Firefox noch ein IE oder Opera konnten mir die Website anzeigen.

Verschiedene Einstellungen zur Contentauslieferung brachten leider keine Hilfe.

Ein Workaround ist nun, einfach alle Files durch den PHP Prozessor laufen zu lassen:

AddType application/x-httpd-php .php .phtml .php3 .html .htm

Dies ist zwar nicht unbedingt die Ressourcen schonend, allerdings funktioniert Mod Layout anschließend.

Die Logfiles die pipelog.pl anspricht werden aber leider auch nicht vom updateskript nachträglich generiert, also musste Hand angelegt werden:

for i in `ls /etc/apache2/confixx_vhosts`
do
  domains=`grep ServerName /etc/apache2/confixx_vhosts/$i | awk '{print $2}'`
  for j in $domains
  do
    ln -s /var/www/`basename $i .conf`/log/access_log /var/log/apache2/confixx/domains/access/$
  done
done

Ist es nicht schön eine bash zu haben? Nach der Generierung der Links liefen auch die awstats Updates wieder:

for i in `ls /var/www/`
do
  /usr/lib/cgi-bin/awstats.pl -config=$i -update
done

Das Bild im VServer

       ?  ? ?---------  ? ?        ?        ?            ? /var/mail/root

Das Bild außerhalb des VServers:

83363649 437981200 ?r-s--S-wt 8224 7217184 6627360 538976288 Jan 30  1987 root

Das ganze klingt ja schon spannend, allerdings lassen sich diese Dateien anschließend auch nicht mehr löschen, geschweige denn lesen:

~# chmod 600 /var/mail/root
chmod: changing permissions of `/var/mail/root': Operation not permitted
~# rm /var/mail/root
rm: remove write-protected weird file `/var/mail/root'? y
rm: cannot remove `/var/mail/root': Operation not permitted

Da allerdings über dmesg keinerlei Einträge auf einen Fehler im Dateisystem hingedeutet haben, war der einzigste Weg die Dateien zu löschen debugfs zu verwenden:

~# debufs
debugfs:  open -w /dev/sda3
debugfs:  cd /var/mail
debugfs:  rm root
debugfs:  close

Wichtig dabei ist das abschließende close, da ansonsten die Änderungen nicht auf das Dateisystem geschrieben werden.

Nun habe ich dank Matty (http://prefetch.net/blog/) einen entscheidenden Tipp bekommen: http://prefetch.net/blog/index.php/2008/07/09/bashs-built-in-commands/

Ich bin davor noch nicht auf die Idee gekommen mit den Keybindings direkt in der Bash herumzuspielen. Dank ihm konnte ich nun so endlich die “entf” Taste in Solaris verwenden:

bind '"\e[3~"':delete-char

Ab in die .bashrc :)

Vielen Dank matty! Du hast mir das Leben erleichtert.

Es zeigte sich nach einem ls auf dessen Homeverzeichniss, dass das Verzeichnis /etc fehle. Da der Kunde mich um eine kurze Fehleranalyse bat, damit sein VServer schnell wieder online kommt.

In /var/log/auth.log zeigte sich zuerst, dass sich root per SSH erfolgreich authentifiziert hatte. Jedoch meinte der Kunde er sei zu dieser Zeit 100% nicht am Rechner gewesen.

Der clou kam dann bei cat /root/.bash_history:

cd ..
ls
cd var
ls
cd kunden/
ls
cd webs/
ls
cd xyz/
ls
wget -r http://www.xyz.de/gallery/
ls
cd www.xyz.de/
ls
rm -all
rm --help
rm -r
rm / -r
ls
ls
cd ..
ls

Tja dies war wohl nicht beabsichtigt. Glücklicherweise hat der Übeltäter seinen Befehl doch sehr schnell abgebrochen, denn die anderen Verzeichnisse gab es noch.

Kurzes Backup der Webpräsenzen und der Kunde durfte seinen VServer neu aufsetzen.

Für mich war die Arbeit somit schnell erledigt, allerdings hat der Kunde nun seine Lektion gelernt wann und wem er anderen Rootrechte gibt.

Diese Sicherheitslücke gibt es leider schon sehr lange (Februar 2006). Da ich mich damit beschäftigen auseinander setzen musste, will ich hier ein kleines Workaround vorstellen mit dem diese Sicherheitslücke geschlossen wird.

Mein Ansatz setzt darauf an, dass ich sage warum braucht ein Kundenmanagementsystem mehrere Adminaccounts.

Ich habe einfach in der admin/add_user.php folgenden code auskommentiert:

/* Sicherheitslücke
$rs = exec_query($sql, $query, array($username,
$upass,
$user_id,
$fname,
$lname,
$firm,
$zip,
$city,
$country,
$email,
$phone,
$fax,
$street1,
$street2));
*/

Dies sind die Zeilen 111 bis 125.

Dies ist absolut nicht perfekt aber eine schnelle und einfache Lösung sein VHCS zu schützen.

Abgesehen davon übernehm ich auch keinerlei Garantie, das dieses Workaround funktioniert. Es ist jedem selbst überlassen ob er es einsetzen will.

Wenn ich Zeit finde werde ich eventuell nach einer besseren Lösung suchen. Für den Moment reicht mir dies jedoch vollkommen.

Ich will euch dieses kleine Skript nicht vorenthalten und deshalb is es hier im Anhang:

#####################################################
# (c) by Oliver Werner (o.werner < [at]> netcup.de) #
#                                                   #
# tool for automaticaly chown confixx web           #
# dirs to the right user and group                  #
# I take absolutly no warranty for this tool        #
#####################################################

use strict;

my $workdir = "/var/www/";  #Set this to the path where your confixx webs are located
my $wwwdata = "www-data";   #Set this to the group name of your apache

#####################################################
# Don't touch anything below this line              #
# expect you are knowing what you are doing!        #
#####################################################

print("Opening Workdir...n");

opendir(WORKDIR, $workdir);
my @dirs = readdir(WORKDIR);
closedir(WORKDIR);

my $output = "";

print("Starting to chown files...n");

foreach my $dirname (@dirs) {
if($dirname =~ /webd+/) {
$output = `chown root:root $workdir$dirname`;
$output = `chown root:$wwwdata $workdir$dirname/atd -R`;
$output = `chown root:$dirname $workdir$dirname/backup -R`;
$output = `chown $dirname:$wwwdata $workdir$dirname/files -R`;
$output = `chown $dirname:$wwwdata $workdir$dirname/html`;
$output = `chown $dirname:$dirname $workdir$dirname/html/* -R`;
$output = `chown root:$dirname $workdir$dirname/log`;
$output = `chown root:root $workdir$dirname/log/* -R`;
$output = `chown $dirname:$wwwdata $workdir$dirname/phptmp -R`;
$output = `chown $dirname:$dirname $workdir$dirname/restore -R`;
}
}

print("All Files and dirs chowned beside errors shown above!n");

Ich übernehme aber keinerlei Verantwortung für jegliche Fehler die dieses kleine Skript verursacht.

Ansonsten ausführen is einfach:

1. Meldet euch als root an: # su

2. Die Datei anlegen und das obige Skript hineinkopieren: # vi /root/chown.pl

3. Die 2 Variablen im Head anpassen: $workdir und $wwwdata
4. Ausführen mit: # perl /root/chown.pl

5. Genießen, dass man so wenig Zeit gebraucht hat.

Vielleicht kann es ja jmd brauchen ;)

Ich werde es in Zukunft auf jeden Fall öfter einsetzen ;)

Doch nun hab ich endlich eine Methode gefunden, wie man das leicht und sinnvoll realisieren kann.

Das ganze geht nun einmal komplett von Debian aus, aber das wird momentan ja eh fast am meisten genutzt, zumindest wenn man mal von dem möchtegern Linux Suse absieht.

Auf jeden Fall war das Problem, dass Confixx ja sasl verwendet um SMTP Sender zu authentifizieren. Das erste Problem ergibt sich darin, den richtigen Befehl zu finden damit man sasl in den postfix jail verlinken kann.

Der folgende Befehl funktioniert bei der Erstinstallation blendend:

mkdir -p /var/spool/postfix/var/run/saslauthd
saslauthd -a shadow -m /var/spool/postfix/var/run/saslauthd

Wehe jedoch man rebootet den Server, danach kann man dann den Befehl gleich nochmals ausführen. Dies ist jedoch auf die dauer lästig. Klar man könnte ein init Skript schreiben doch das löst selten alle Probleme.

Auf eine einfache Lösung bin ich heute gestoßen: http://holl.co.at/howto-email/#a2.2
Man lässt den saslauth Daemon direkt mit dem richtigen Verzeichnis starten, da es im sonstigen System eh nicht genutzt wird:

Datei /etc/default/saslauthd editieren und folgende Sachen anpassen:

MECHANISMS=”shadow”
PARAMS=”-m /var/spool/postfix/var/run/saslauthd”
PWDIR=”/var/spool/postfix/var/run/saslauthd”

Danach den Daemon neu starten (/etc/init.d/saslauthd restart) und anschließend am besten noch postfix, damit der das auch wirklich richtig merkt und in seinen Speicher mit aufnimmt.

Nun sollte man sich am besten per Telnet am SMTP anmelden und richtig authentifizieren, da man so am schnellsten die Fehler findet.

Treten Fehler wie generic failure auf, dann kann es an folgenden beiden Fällen liegen:

1. Postfix mag komischerweise keinen sasl smtp -> apt-get install postfix-tls

2. Das saslauthd hat die falschen Zugriffsrechte: dpkg-statoverride –add root root 755 /var/spool/postfix/var/run/saslauthd

Ob dies nun eine Sicherheitslücke enthält wird noch intern von der Penetration Testing Abteilung getestet.

So evtl hilft es ja jemandem weiter. Vielen Dank noch an den Autor der oben genannten Website.