Zugriff auf Datenbanken aus Chroot Umgebung

[pennywize]

Guten Abend,

die Firma von meinem Vater will sich ab nächsten Monaten online präsentieren. Momentan befinde ich mich noch auf einer virtuellen Testumgebung, der Rootserver steht in ca 14 Tagen bereit.
Was ich bisher gemacht habe:

1. Testumgebung Debian Sarge
2. Apache2+PHP5.1.6 in einer chrooted Umgebung erstellt, funktioniert.
3. MySQL 4.1 und Postfix in chroot erstellt, funktioniert
4. Zugriff auf MySQL Datenbanken aus chroot Umgebung á la "mysql_connect('127.0.0.1:3306','username','passwort');"

Jetzt komme ich zu meinem Problem bzw Verständnisproblem. Ich erstelle über die Konsole Useraccounts, übergebe diese an die MySQL Datenbank und Postfix kommt an die Datenbank über 127.0.0.1:3306 problemlos an die Datenbanken ran.
Beim Versuch mit phpmyadmin die Datenbank zu bearbeiten erscheinen folgende Fehler, die offensichtlich bei den Rechten ihren Ursprung finden:

Code: Select all

Warning: session_write_close() [function.session-write-close]: open(/tmp/sess_Qh2mxldLqW5ydeYdNkppYz-G2t2, O_RDWR) failed: Permission denied (13) in /var/www/htdocs/aaa/index.php on line 44

Warning: session_write_close() [function.session-write-close]: Failed to write session data (files). Please verify that the current setting of session.save_path is correct () in /var/www/htdocs/aaa/index.php on line 44

Warning: Cannot modify header information - headers already sent by (output started at /var/www/htdocs/aaa/index.php:44) in /var/www/htdocs/aaa/index.php on line 101[/cod[code]e]

phpmyadmin ist so konfiguriert

Code: Select all

$cfg['Servers'][$i]['host']          = '127.0.0.1'; 
$cfg['Servers'][$i]['port']          = '3306';          
$cfg['Servers'][$i]['socket']        = '';   
$cfg['Servers'][$i]['connect_type']  = 'tcp';

In jedem chroot existiert nur der jeweilige Benutzer von Apache2, MySQL bzw Postfix.
Meine Frage lautet, müssen noch irgendwelche Einstellungen vorgenommen werden um Datenbanken mit phpmyadmin bearbeiten zu können?
Würdet Ihr mir aus Gründen der Sicherheit raten darauf zu verzichten? Es ist ja nicht so, dass ich mit der Konsole und den SQL Syntax nicht vertraut bin, würde sich aber mit einer Oberfläche etwas schneller machen lassen.

Bin für jeden Hinweis, Ratschlag dankbar

[Roger Wilco]

Lies bitte die Fehlermeldungen nochmal. Das Problem liegt nicht an phpMyAdmin oder der MySQL-Datenbank, sondern an dem Verzeichnis /tmp, das in deiner chroot-Umgebung entweder nicht existiert oder die falschen Rechte besitzt.

[pennywize]

Lies bitte die Fehlermeldungen nochmal. Das Problem liegt nicht an phpMyAdmin oder der MySQL-Datenbank, sondern an dem Verzeichnis /tmp, das in deiner chroot-Umgebung entweder nicht existiert oder die falschen Rechte besitzt.

:oops:

Hatte das Verzeichnis erstellt, aber mit chmod -R 700 tmp wollte es nicht klappen.
Hab jetzt noch eine Frage, gesetzt den Fall ich würde noch mod_security installieren, wäre das für einen Apachen in einer chroot-Umgebung überhaupt sinnvoll oder reiner Schwachsinn?

[Roger Wilco]

Einzelne kritische und besonders exponierte Dienste in ein chroot/Jail/VPS zu stecken ist IMHO immer sinnvoll.

[sledge0303]

Es kommt immer drauf an. Ich selber mache es abhängig was auf dem Apachen laufen soll. Sollte jemand schlecht programmierte Skripte auf einen CHROOTed Apachen laufen lassen, eine Dritte Person findet die schwache Stelle und dringt direkt in das Jail ein, stehen dessen Chancen schlecht etwas schädliches anzustellen.

Unabhängig davon sind generell Sicherheitslücken nicht immer in den CHROOTed Diensten wie Apache zu suchen, es fängt schon mit dem SSH Login, Kernel und den Benutzern (deren Rechte) sowie dessen verwendete Passwörter an.

Gerade darauf solltest deine erste Aufmerksamkeit richten bevor mit all anderem Krams anfängst.

Deine Idee mit dem virtuellen Server zu Hause zuerst alles testen zu wollen, bevor du eine Kiste online in das Netz stellst, ist schon viel wert. Wäre wünschenswert wenn sich einige wannabe Admins eine Scheibe abschneiden würden ;)

[lucki2]

Code: Select all

chmod  777 /chroot/tmp

immer. Außer Du kennst dich gut aus und kannst Deine Programme anpassen.
Was anderes, weil Du nach Sicherheit frägst: Ein Tipp: schiebe Deine PHP-Session aus dem /tmp woandershin - eben weil /tmp 777 ist.

[captaincrunch]

chmod 777 /chroot/tmp

Wie wär's denn einfach mal standardgemäß und sinniger mit 1777?

[pennywize]

Erstmal vielen Dank Euch allen für die Hinweise. Mit dem $CHROOT/tmp wurde erstmal angepasst. Meine Überlegungen sind, um es noch sicherer zu machen, temporäre Verzeichnisse auszulagern und in ein eigenes chroot zu stecken. Ein Versuch ist es wert und man bleibt beim testen ja nicht blöd :)
Hat das jemand mal ausprobiert bzw. es läuft schon und hat Erfahrungswerte sammeln können?
Mir ging es erstmal um die Frage, ob mod_security unbedingt in einer Apache chroot Umgebung gehört oder nicht.

[lord_pinhead]

Unbedingt gehört mod_sec nicht in einer chroot, schaden kann es aber überhaupt nicht. Du solltest dir vielleicht auch mal auf http://www.hardened-php.net/ Suhosin ansehen. Lässt du den Webserver einfach so laufen oder nutzt du eigentlich suexec/suphp?

Ausserdem, wäre es nicht sinnvoller das Session Verzeichniss zu verlegen inkl. upload_temp_dir? So wie in dem Beispiel:

Code: Select all

php_admin_value session_path /srv/vhost/phpsession/
php_admin_value upload_temp_dir /srv/vhost/phptemp/
php_admin_value open_basedir /srv/vhost/

Dann kann er /tmp sperren ohne das es Probleme machen dürfte.

[sledge0303]

Unbedingt gehört mod_sec nicht in einer chroot, schaden kann es aber überhaupt nicht. Du solltest dir vielleicht auch mal auf http://www.hardened-php.net/ Suhosin ansehen. Lässt du den Webserver einfach so laufen oder nutzt du eigentlich suexec/suphp?

Ausserdem, wäre es nicht sinnvoller das Session Verzeichniss zu verlegen inkl. upload_temp_dir? So wie in dem Beispiel:

Code: Select all

php_admin_value session_path /srv/vhost/phpsession/
php_admin_value upload_temp_dir /srv/vhost/phptemp/
php_admin_value open_basedir /srv/vhost/

Dann kann er /tmp sperren ohne das es Probleme machen dürfte.

Das sind schon gute Optionen mit dem verlegen der PHP Sessions. Wenn er nur einen User in seiner CHROOTed Apache Umgebung hat, wird er PHP als Modul inkludiert haben.

Mit dem mod_security kann man sich streiten. Schaden kann es auf der einen Seite nicht, auf der anderen Seite kann es zu einem hohen Performanceverlust kommen.

@pennywize
Den Part mit dem eigenen chroot für temp Dateien hab ich nicht so richtig verstanden. Wie soll der Zugriff aussehen, TCP/IP etwa?
Worin würdest du den Vorteil bzw. eine erhöhte Sicherheit sehen?

[lucki2]

1777

Doch, macht Sinn.

[pennywize]

@sledge0303

Bei der Sache mit dem chroot /tmp hast recht, es wäre bestimmt machbar aber würde keinen Sicherheitsgewinn bringen.
Zur Zeit läuft PHP5.1.6 als Modul. Nun hab ich mir ein CGI gebastelt, FastCGI installiert und während des Tests wird mir folgende Fehlermeldung präsentiert:

Code: Select all

/var/chroot/apache2/etc/apache2/mods-enabled# /etc/init.d/apache restart
Forcing reload of web server: Apache2Warning: SuexecUserGroup directive requires SUEXEC wrapper.
Warning: SuexecUserGroup directive requires SUEXEC wrapper.

Kommentiere ich in der FCGI.conf

Code: Select all

#FastCgiWrapper /usr/lib/apache2/suexec2

aus, wird mir zwar die Meldung angezeigt, das die Direktive SUEXEC wrapper erforderlich ist und das die Angaben User/Gruppe ignoriert werden, doch PHP Skripte werden aufgerufen ohne Errors in den Logs.

Der User im chroot "apache2chroot" hat UID/GID 104
suexec2:

Code: Select all

ls -la suexec2
-rwxr-xr-x  1 apache2chroot apache2chroot 10596 Oct 24 00:57 suexec2

also 4755

Muss mir nochmal das Manual durchlesen, habe bestimmt eine Kleinigkeit übersehen... :?:


@LordPinhead

Danke für den Tipp, wenn ich das andere Problem beseitigt habe wird das mal umgesetzt :)