Scriptsammlung isolierter Vhost

[Tim Ritberg]

Hi!

Gibt es/hat jemand Scripte, die mir isolierte Apache-Vhosts anlegen?
Also einen Webuser für ein Verzeichnis und für FPM, dazu die passender
PHP-config und den Vhost?

Nutzt man da am besten das ITK-MPM?

Tim

[Arno Welzel]

Tim Ritberg:

> Gibt es/hat jemand Scripte, die mir isolierte Apache-Vhosts anlegen?

Ja. Aber die sind nicht Open Source.

> Also einen Webuser für ein Verzeichnis und für FPM, dazu die passender
> PHP-config und den Vhost?

Das ist ja nicht allzu schwierig. Was genau fehlt Dir denn dazu?

> Nutzt man da am besten das ITK-MPM?

Nein, tut man nicht. Nicht Apache soll mit einem anderen User laufen,
sondern PHP. Und letzteres erreicht man, indem man PHP-FPM nutzt und den
Pool entsprechend konfiguriert, den gewünschten User zu verwenden.

In Apache nutzt man vorzugsweise mpm_worker oder mpm_event und bindet
PHP über proxy_fcgi ein.

--
Arno Welzel
https://arnowelzel.de

[Tim Ritberg]

Am 14.06.22 um 14:07 schrieb Arno Welzel:

> Tim Ritberg:
>
>> Gibt es/hat jemand Scripte, die mir isolierte Apache-Vhosts anlegen?
>
> Ja. Aber die sind nicht Open Source.

Woher?

>
>> Also einen Webuser für ein Verzeichnis und für FPM, dazu die passender
>> PHP-config und den Vhost?
>
> Das ist ja nicht allzu schwierig. Was genau fehlt Dir denn dazu?

Zeit

>
>> Nutzt man da am besten das ITK-MPM?
>
> Nein, tut man nicht. Nicht Apache soll mit einem anderen User laufen,
> sondern PHP. Und letzteres erreicht man, indem man PHP-FPM nutzt und den
> Pool entsprechend konfiguriert, den gewünschten User zu verwenden.
>
> In Apache nutzt man vorzugsweise mpm_worker oder mpm_event und bindet
> PHP über proxy_fcgi ein.
>

Ja nee, ja doch!
Also wie sollen sonst jpg und css ausgeliefert werden?

Tim

[Arno Welzel]

Tim Ritberg:

>
> Am 14.06.22 um 14:07 schrieb Arno Welzel:
>> Tim Ritberg:
>>
>>> Gibt es/hat jemand Scripte, die mir isolierte Apache-Vhosts anlegen?
>>
>> Ja. Aber die sind nicht Open Source.
> Woher?

Selbst erstellt.

>>> Also einen Webuser für ein Verzeichnis und für FPM, dazu die passender
>>> PHP-config und den Vhost?
>>
>> Das ist ja nicht allzu schwierig. Was genau fehlt Dir denn dazu?
> Zeit

Kann man ggf. mit Geld ausgleichen - bei mir aber erst wieder nach dem
20. Juni 2022 ;-).

Lieferumfang:

Script, was einen User anlegt, die Apache-VHost-Konfiguration und
PHP-FPM-Konfiguration. Allerdings ohne ITK, da sich das in der Praxis
als unbrauchbar für ernsthaften Betrieb mit mehreren hundert Zugriffen
pro Sekunde erwiesen hat.

>>> Nutzt man da am besten das ITK-MPM?
>>
>> Nein, tut man nicht. Nicht Apache soll mit einem anderen User laufen,
>> sondern PHP. Und letzteres erreicht man, indem man PHP-FPM nutzt und den
>> Pool entsprechend konfiguriert, den gewünschten User zu verwenden.
>>
>> In Apache nutzt man vorzugsweise mpm_worker oder mpm_event und bindet
>> PHP über proxy_fcgi ein.
>>
> Ja nee, ja doch!
> Also wie sollen sonst jpg und css ausgeliefert werden?

Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.

Generell ist ITK einfach nicht zu empfehlen - BTDT. Spätestens wenn man
mehr als ein paar Dutzend Zugriffe pro Sekunde bedienen will, merkt man
das sehr deutlich. Hinzu kommt, dass dieser "Hack" das letzte Mal vor
über 6(!) Jahren aktualisiert wurde: <http://mpm-itk.sesse.net>

[Tim Ritberg]

Am 14.06.22 um 16:57 schrieb Arno Welzel:

>> Ja nee, ja doch!
>> Also wie sollen sonst jpg und css ausgeliefert werden?
>
> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.

Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle
Vhosts zugreifen kann.

>
> Generell ist ITK einfach nicht zu empfehlen - BTDT. Spätestens wenn man
> mehr als ein paar Dutzend Zugriffe pro Sekunde bedienen will, merkt man
> das sehr deutlich. Hinzu kommt, dass dieser "Hack" das letzte Mal vor
> über 6(!) Jahren aktualisiert wurde: <http://mpm-itk.sesse.net>

Das ist jetzt aber wirklich schlecht. s.o.

Tim

[Karl Pflästerer]

Tim Ritberg <t...@server.invalid> writes:

> Am 14.06.22 um 16:57 schrieb Arno Welzel:
>>> Ja nee, ja doch!
>>> Also wie sollen sonst jpg und css ausgeliefert werden?
>> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.
> Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle Vhosts
> zugreifen kann.

Wie meinst du das?
jeder VHost hat ein einen DocumentRoot. Wenn du nicht zu sehr mit Alias,
Symlinks mod_rewrite spielst gibt es da auch keine Lücken.
www_data darf nur lesen nicht schreiben.
Also an welche Art von Angriff denkst du?

Ich erstelle hier auch VHosts und fpm_config automatisiert. Ist kein
Hexenwerk. Unter Ubuntu/Debian gibt es /etc/php/8.0/fpm/pool.d/
In dieses Verzeichnis kommen per Ansible Symlinks auf die Pool Confifs
jedes einzelnen Webprozesses. Deploymnet per Ansible hier ist so, das
geschaut wird, welche Pool Configs existieren und je Pool Conig kommt
ein Symlink in pool.d. Anscjließned startet Ansible den Fpm Daemin neu.
In der Pool Config stehen die Adressen der Unix Domain Sockets über die
der datentransfer läuft. jeder Apche VHost hat einen eigenen Pool mit
eigenem Socket.


Das ist hier ganz praktisch, weil das Deployment der Webserver Config
nicht mit Root Rechten erfolgen muss. Die Erstellung der Symlinks
allerdings schon.

Ein ähnliches Vorgehen gibt es auch für Nginx und fpm.

[Tim Ritberg]

Am 15.06.22 um 11:18 schrieb Karl Pflästerer:

> Tim Ritberg <t...@server.invalid> writes:
>
>> Am 14.06.22 um 16:57 schrieb Arno Welzel:
>>>> Ja nee, ja doch!
>>>> Also wie sollen sonst jpg und css ausgeliefert werden?
>>> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.
>> Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle Vhosts
>> zugreifen kann.
>
> Wie meinst du das?
> jeder VHost hat ein einen DocumentRoot. Wenn du nicht zu sehr mit Alias,
> Symlinks mod_rewrite spielst gibt es da auch keine Lücken.
> www_data darf nur lesen nicht schreiben.
> Also an welche Art von Angriff denkst du?

Durchhangeln auf andere Vhost. www-data kann ja an alle Installationen.
Bei ITK ist das nicht möglich, weil die "Apache-childs" mit
verschiedenen Usern laufen. Da müsste man schon in den Elternprozess
(root) ausbrechen.

>
> Ich erstelle hier auch VHosts und fpm_config automatisiert. Ist kein
> Hexenwerk. Unter Ubuntu/Debian gibt es /etc/php/8.0/fpm/pool.d/
> In dieses Verzeichnis kommen per Ansible Symlinks auf die Pool Confifs
> jedes einzelnen Webprozesses. Deploymnet per Ansible hier ist so, das
> geschaut wird, welche Pool Configs existieren und je Pool Conig kommt
> ein Symlink in pool.d. Anscjließned startet Ansible den Fpm Daemin neu.
> In der Pool Config stehen die Adressen der Unix Domain Sockets über die
> der datentransfer läuft. jeder Apche VHost hat einen eigenen Pool mit
> eigenem Socket.

Bash wäre mir lieber.

Tim

[Karl Pflästerer]

Tim Ritberg <t...@server.invalid> writes:

> Am 15.06.22 um 11:18 schrieb Karl Pflästerer:
>> Tim Ritberg <t...@server.invalid> writes:
>>
>>> Am 14.06.22 um 16:57 schrieb Arno Welzel:
>>>>> Ja nee, ja doch!
>>>>> Also wie sollen sonst jpg und css ausgeliefert werden?
>>>> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.
>>> Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle Vhosts
>>> zugreifen kann.
>> Wie meinst du das?
>> jeder VHost hat ein einen DocumentRoot. Wenn du nicht zu sehr mit Alias,
>> Symlinks mod_rewrite spielst gibt es da auch keine Lücken.
>> www_data darf nur lesen nicht schreiben.
>> Also an welche Art von Angriff denkst du?
> Durchhangeln auf andere Vhost. www-data kann ja an alle Installationen.
> Bei ITK ist das nicht möglich, weil die "Apache-childs" mit verschiedenen
> Usern laufen. Da müsste man schon in den Elternprozess (root) ausbrechen.

Und wie soll das gehen?

VHost 1
<VirtualHost *:443>
ServerName vhost1
DocumeentRoot /opt/www/vhost1
<Directory "/opt/www/vhost1">
AllowOverride None
Require all granted
</Directory>
</VirtualHost>


VHost 2
<VirtualHost *:443>
ServerName vhost2
DocumeentRoot /opt/www/vhost2
<Directory "/opt/www/vhost2">
AllowOverride None
Require all granted
</Directory>
</VirtualHost>


In der httpd.conf hast du
<Directory />
AllowOverride none
Require all denied
</Directory>


Wie kann sich jetzt "durchhangeln"? Wenn du davon ausgehst, dass man
auf VHost1 eine Webshell hochladen und ausführen konnte, kommt es auf
die Nutzerrechte der anderen Installationen eher weniger an. Schaden ist
auch so schon da.
Umn zu wissen, was du verhindern willst, fehlt die konkrete Beschreibung
des Angriffs.

>
>> Ich erstelle hier auch VHosts und fpm_config automatisiert. Ist kein
>> Hexenwerk. Unter Ubuntu/Debian gibt es /etc/php/8.0/fpm/pool.d/
>> In dieses Verzeichnis kommen per Ansible Symlinks auf die Pool Confifs
>> jedes einzelnen Webprozesses. Deploymnet per Ansible hier ist so, das
>> geschaut wird, welche Pool Configs existieren und je Pool Conig kommt
>> ein Symlink in pool.d. Anscjließned startet Ansible den Fpm Daemin neu.
>> In der Pool Config stehen die Adressen der Unix Domain Sockets über die
>> der datentransfer läuft. jeder Apche VHost hat einen eigenen Pool mit
>> eigenem Socket.
> Bash wäre mir lieber.

Hält dich doch niemand von ab. Wenn es nur ein oder 2 Server sind, die
du betreust, ist das problemlos machbar.
Wenn du etwas Spieltrieb hast, nimmst du m4 für die Templates. Ansonsten
geht zur Not auch bash und sed. Hängt halt sehr davon ab, wie du
arbeitest



KP

[Tim Ritberg]

Am 15.06.22 um 16:58 schrieb Karl Pflästerer:

>
>
> Wie kann sich jetzt "durchhangeln"? Wenn du davon ausgehst, dass man
> auf VHost1 eine Webshell hochladen und ausführen konnte, kommt es auf
> die Nutzerrechte der anderen Installationen eher weniger an. Schaden ist
> auch so schon da.
> Umn zu wissen, was du verhindern willst, fehlt die konkrete Beschreibung
> des Angriffs.

Ich meinte einen Angriff auf den Prozess httpd (apache2).

>
> Hält dich doch niemand von ab. Wenn es nur ein oder 2 Server sind, die
> du betreust, ist das problemlos machbar.
> Wenn du etwas Spieltrieb hast, nimmst du m4 für die Templates. Ansonsten
> geht zur Not auch bash und sed. Hängt halt sehr davon ab, wie du
> arbeitest

m4...da fällt mir sendmail ein. Aber richtig hatte ich damit nie zutun.

Tim

[Karl Pflästerer]

Tim Ritberg <t...@server.invalid> writes:

> Am 15.06.22 um 16:58 schrieb Karl Pflästerer:
>
>>
>> Wie kann sich jetzt "durchhangeln"? Wenn du davon ausgehst, dass man
>> auf VHost1 eine Webshell hochladen und ausführen konnte, kommt es auf
>> die Nutzerrechte der anderen Installationen eher weniger an. Schaden ist
>> auch so schon da.
>> Umn zu wissen, was du verhindern willst, fehlt die konkrete Beschreibung
>> des Angriffs.
> Ich meinte einen Angriff auf den Prozess httpd (apache2).

Und wie genau?

>
>> Hält dich doch niemand von ab. Wenn es nur ein oder 2 Server sind, die
>> du betreust, ist das problemlos machbar.
>> Wenn du etwas Spieltrieb hast, nimmst du m4 für die Templates. Ansonsten
>> geht zur Not auch bash und sed. Hängt halt sehr davon ab, wie du
>> arbeitest
> m4...da fällt mir sendmail ein. Aber richtig hatte ich damit nie zutun.

Das einzige Programm mit turing vollständiger Config Sprache :-)
Wie gesagt, würde ich nehmen, wenn ich auch Spaß dabei haben wollte.

Wenn nicht ist ein kleines Perl/Python Skript besser

ZB in Perl:

#!/usr/bin/perl

use strict;
use warnings;
my $base = '/path/to/dir';
my $dst_base = $base . 'devel/';
my $templatefile = $ARGV[0] || $base . 'vhost-devel-template.conf';
(my $ntemplate = $templatefile) =~ s/template/%s/;
$ntemplate = $dst_base . (split /\//, $ntemplate)[-1];
my @names = map { m/_devel-([^\/]+)/ } < '/path/to/dir/_devel*' >;

open my $fh, '<', $templatefile or die "$templatefile $!";

my $template = do { local ($/); <$fh> };
close $fh;

for my $name (@names) {
open my $fh, '>', sprintf($ntemplate, $name) or die sprintf($ntemplate.$!, $name);
my $text = $template;
$text =~ s/{NAME}/\U$name/g;
$text =~ s/{name}/\L$name/g;
print $fh $text;
close $fh;
}


Das erstellt VHost dateien für Entwickler. Die Namen sind aus
Verzeichnisnamen ermittelbar. Je Name werden Platzhalter im Tempalte
ersetzt. Wenn du mehr Platzhalter benötigst einfach noch ein paar s///,
Zeilen rein. Platzhalter ist {name} und {NAME} um den gleichen wert
definiert groß- oder kleingeschrieben auszugeben. Das gleiche gibt es
auch als Python Variante.


KP

[Stefan Froehlich]

On Wed, 15 Jun 2022 19:43:10 Karl Pflästerer wrote:
> #!/usr/bin/perl
>
> use strict;
> use warnings;
> my $base = '/path/to/dir';
> my $dst_base = $base . 'devel/';
> my $templatefile = $ARGV[0] || $base . 'vhost-devel-template.conf';
> (my $ntemplate = $templatefile) =~ s/template/%s/;
> $ntemplate = $dst_base . (split /\//, $ntemplate)[-1];
> my @names = map { m/_devel-([^\/]+)/ } < '/path/to/dir/_devel*' >;
>
> open my $fh, '<', $templatefile or die "$templatefile $!";
>
> my $template = do { local ($/); <$fh> };
> close $fh;
>
> for my $name (@names) {
> open my $fh, '>', sprintf($ntemplate, $name) or die sprintf($ntemplate.$!, $name);
> my $text = $template;
> $text =~ s/{NAME}/\U$name/g;
> $text =~ s/{name}/\L$name/g;
> print $fh $text;
> close $fh;
> }

> Das erstellt VHost dateien für Entwickler.

Das erinnert mich daran, dass ich irgendwann in den 90ern einmal
eine umfangreichere Apachekonfiguration erstellt habe, die (via
mod_perl) den Code *innerhalb* der Konfiguration stehen hatte.

Im Grund genommen lief das ähnich wie von Dir skizziert, nur
brauchte man nicht als Zwischenschritt Config-Dateien zu erstellen,
die anschließend eingebunden wurde, sondern die Konfiguration
generierte sich gewissermaßen on-the-fly selbst.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Schmusen mit Stefan - reizvoll werden mit Eleganz.
(Sloganizer)

[Tim Ritberg]

Am 15.06.22 um 19:43 schrieb Karl Pflästerer:

> Tim Ritberg <t...@server.invalid> writes:
>
>> Am 15.06.22 um 16:58 schrieb Karl Pflästerer:
>>
>>>
>>> Wie kann sich jetzt "durchhangeln"? Wenn du davon ausgehst, dass man
>>> auf VHost1 eine Webshell hochladen und ausführen konnte, kommt es auf
>>> die Nutzerrechte der anderen Installationen eher weniger an. Schaden ist
>>> auch so schon da.
>>> Umn zu wissen, was du verhindern willst, fehlt die konkrete Beschreibung
>>> des Angriffs.
>> Ich meinte einen Angriff auf den Prozess httpd (apache2).
>
> Und wie genau?

Man nennt es "bug".

https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/

Tim

[Karl Pflästerer]

Ja und? Du verwendest lieber eine alte nicht mehr gewartete Apache
Extension (letzte Version 2016) als Apache mit aktuell betreuten
Modulen, bei denen man eher davon ausgehen kann, das Bugs gefunden und
behoben werden? Verstehe ich nicht.
Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
Trennung strikter sein (mit zB Docker Container kein so großer
Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
will.



KP

[Karl Pflästerer]

So was hatte ich früher auch mal (noch Apsche 1.3.xx und mod perl 1)
Fand es aber übersichtlicher die Configs mit Präprozessor automatisch zu
erstellen und dann die ganze Logik in Apache Handler zu packen. mod_perl
war super aber bis es mit Apache 2.4 kompatibel war, dauerte es zu
lange.
Heute nutze ich mod_lua wo es sinnvoll ist. Logik im Server zu haben.
Ohne mod_perl ist Apache deutlich stabiler. Lua hat einen Bruchteil der
Größe von Perl.
Die mod_perl Adaption ging gefühlt seit Apache 2 sehr zurück. Das Tolle
von mod_perl (die enge Integration mit Apache, der Zugriff auf alle
handler Phasen, die man sonst nur mit C erreichte), war auch das Problem
als ide interne Apache API sich von 1.3 zu Apache 2 so massiv ämderte.
Die man power fehlte zeitnah mod_perl weiter zu entwicklen.

> Im Grund genommen lief das ähnich wie von Dir skizziert, nur
> brauchte man nicht als Zwischenschritt Config-Dateien zu erstellen,
> die anschließend eingebunden wurde, sondern die Konfiguration
> generierte sich gewissermaßen on-the-fly selbst.

Ich hatte ziemlich viel mit mod_perl gemacht; den dynamischen Config
Teil fanf ich nie so überzeugend verglchen damit, die Config Dateien
zuvor aus templates zu erstellen (sofern zur Compile Zeit die notwendige
Information bekannt ist).

[Tim Ritberg]

Am 15.06.22 um 22:28 schrieb Karl Pflästerer:

>> Man nennt es "bug".
>>
>> https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/
>
> Ja und? Du verwendest lieber eine alte nicht mehr gewartete Apache
> Extension (letzte Version 2016) als Apache mit aktuell betreuten
> Modulen, bei denen man eher davon ausgehen kann, das Bugs gefunden und
> behoben werden? Verstehe ich nicht.

Ich merks. Scheint heut nicht dein Tag zu sein.

> Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
> gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
> Trennung strikter sein (mit zB Docker Container kein so großer
> Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
> will.

Feindlich hin oder her, Security per Design, alles mit www-data laufen
zu lassen ist dumm.
Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine
Rolle spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.

Tim

[Laurenz Trossel]

On 2022-06-15, Tim Ritberg <t...@server.invalid> wrote:

> Feindlich hin oder her, Security per Design, alles mit www-data laufen
> zu lassen ist dumm.
> Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine
> Rolle spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.

Dir ist aber schon aufgefallen, daß im ITK-Modell das kritische Parsen der
Requests als root passiert? Damit hat jeder Bug in diesem Teil die
Möglichkeit, das gesamte System zu übernehmen.

Wenn du die vhosts so weit isolieren willst, dann steck jeden in einen
eigenen Container und setze einen Proxy davor. Alles andere ist Gebastel.

[Tim Ritberg]

Am 15.06.22 um 23:32 schrieb Laurenz Trossel:

> Dir ist aber schon aufgefallen, daß im ITK-Modell das kritische Parsen der
> Requests als root passiert? Damit hat jeder Bug in diesem Teil die
> Möglichkeit, das gesamte System zu übernehmen.

Na dann ein anderes Modul mit User-Change. Leider gibts mod_privileges
nur für Solaris.
mpm-peruser ist uralt und mod_unixd scheint es für Debian gar nicht zu
geben. Komisch...

Tim

[Laurenz Trossel]

On 2022-06-15, Tim Ritberg <t...@server.invalid> wrote:

> Na dann ein anderes Modul mit User-Change. Leider gibts mod_privileges
> nur für Solaris.
> mpm-peruser ist uralt und mod_unixd scheint es für Debian gar nicht zu
> geben. Komisch...

Praktisch jeder user-change erfordert einen Weg über Code, der mit
root-Rechten agiert. Du erwartest etwas von Apache, für das es nicht
ausgelegt ist.

Du kannst jedem vhost einen eigenen httpd-Prozess geben. Das hilft im Falle
eines Bugs auch nur begrenzt, wenn alle im selben System laufen. Wer Code
ausführen kann, kann auch uid 0 erreichen.

Warum willst du lieber mit exotischem Snakeoil hantieren anstatt zu
containern?

[Laurenz Trossel]

On 2022-06-15, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:

> Das erinnert mich daran, dass ich irgendwann in den 90ern einmal
> eine umfangreichere Apachekonfiguration erstellt habe, die (via
> mod_perl) den Code *innerhalb* der Konfiguration stehen hatte.

https://www.varnish-software.com/developers/tutorials/varnish-configuration-language-vcl/

[Tim Ritberg]

Am 16.06.22 um 01:21 schrieb Laurenz Trossel:

> Praktisch jeder user-change erfordert einen Weg über Code, der mit
> root-Rechten agiert. Du erwartest etwas von Apache, für das es nicht
> ausgelegt ist.

Ich hatte da Dovecot im Kopf, der macht das so. Vielleicht kommt das ja
mit Apache 2.6.

>
> Du kannst jedem vhost einen eigenen httpd-Prozess geben. Das hilft im Falle
> eines Bugs auch nur begrenzt, wenn alle im selben System laufen. Wer Code
> ausführen kann, kann auch uid 0 erreichen.

Wie geht das denn?

Und so oder so kann ein Prozess bei Fehlern root werden.

> Warum willst du lieber mit exotischem Snakeoil hantieren anstatt zu
> containern?

Wieso willst du exotische Container und nicht ein bewährtes Unix-Konzept?

Tim

[Stefan Froehlich]

On Wed, 15 Jun 2022 22:39:39 Karl Pflästerer wrote:
> Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:
>> Das erinnert mich daran, dass ich irgendwann in den 90ern einmal
>> eine umfangreichere Apachekonfiguration erstellt habe, die (via
>> mod_perl) den Code *innerhalb* der Konfiguration stehen hatte.

> So was hatte ich früher auch mal (noch Apsche 1.3.xx und mod perl
> 1) Fand es aber übersichtlicher die Configs mit Präprozessor
> automatisch zu erstellen und dann die ganze Logik in Apache
> Handler zu packen. mod_perl war super aber bis es mit Apache 2.4
> kompatibel war, dauerte es zu lange.

Ich würde das heute auch nicht mehr so machen - zumal, weil ich für
den Inhalt aller vhosts auf meinem Server selber verantwortlich bin
und daher deren Konfiguration dort am besten aufgehoben ist. In der
Praxis habe ich ein <Macro>, mit dem sich >90% der Fälle abbilden
lassen, damit reicht mir je vhost ein Einzeiler.

Wäre ich, so wie damals, lediglich für den friktionsfreien Betrieb
vom Apache zuständig, würde ich vielleicht immer noch die Logik
direkt in die Konfiguration packen, weil mir so am schwersten jemand
etwas kaputtmachen kann. Das war damals vielleicht nicht sehr
elegant, aber unglaublich effizient - ich musste das Teil über viele
Monate hinweg so gut wie nicht mehr angreifen.

Und da ich den Anwendungsfall hier nicht im Detail kenne... besser
man weiss, welche Optionen überhaupt zur Verfügung stehen.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Egal ob Kanzler oder Kuli: Stefan - drei mal täglich!
(Sloganizer)

[Tim Ritberg]

Am 15.06.22 um 19:43 schrieb Karl Pflästerer:

>...

>
> Das erstellt VHost dateien für Entwickler. Die Namen sind aus
> Verzeichnisnamen ermittelbar. Je Name werden Platzhalter im Tempalte
> ersetzt. Wenn du mehr Platzhalter benötigst einfach noch ein paar s///,
> Zeilen rein. Platzhalter ist {name} und {NAME} um den gleichen wert
> definiert groß- oder kleingeschrieben auszugeben. Das gleiche gibt es
> auch als Python Variante.
>

Warum so kompliziert. Da nimmt man vhost_alias.


Tim

[Laurenz Trossel]

On 2022-06-16, Tim Ritberg <t...@server.invalid> wrote:
> Am 16.06.22 um 01:21 schrieb Laurenz Trossel:
>> Praktisch jeder user-change erfordert einen Weg über Code, der mit
>> root-Rechten agiert. Du erwartest etwas von Apache, für das es nicht
>> ausgelegt ist.
> Ich hatte da Dovecot im Kopf, der macht das so.

Nur in bestimmten Konfigurationen. Die Dovecot-Installationen in meinem
Umfeld haben keine Unix-User für die Mailboxen. Dovecot verwaltet die User
intern, der Prozess selber läuft unter der dovecot uid.

> Vielleicht kommt das ja mit Apache 2.6.

Ich sehe davon noch nichts.
https://httpd.apache.org/docs/trunk/en/new_features_2_6.html

>> Du kannst jedem vhost einen eigenen httpd-Prozess geben. Das hilft im Falle
>> eines Bugs auch nur begrenzt, wenn alle im selben System laufen. Wer Code
>> ausführen kann, kann auch uid 0 erreichen.
> Wie geht das denn?

Local Root Lücken gibt es in jedem System. Das hält einen kompetenten
Angreifer nicht lange auf.

> Und so oder so kann ein Prozess bei Fehlern root werden.

Darum ist es besser, die Prozesse voneinander zu isolieren und in eigenen
Namespaces zu kapseln.

>> Warum willst du lieber mit exotischem Snakeoil hantieren anstatt zu
>> containern?
> Wieso willst du exotische Container und nicht ein bewährtes Unix-Konzept?

Das Fehlen dieses Unix-Konzepts im konkreten Anwendungsfall ist genau der
Punkt deines OP. Offenbar braucht das bisher kaum jemand.

Multi-Tenant-vhosts laufen entweder im gleichen System und das Risiko
übergreifender Leserechte wird akzeptiert. Oder sie werden getrennt. Früher
mit eigenem Eisen pro Kunde/vhost (SunBros ausgenommen), heute mit
Container.

Container sind zudem nicht exotisch sondern abgehangener Bestandteil des
Linux-Kernels.

man 7 namespaces

[Karl Pflästerer]

Du kennst die genaue Anwendung hier? Nein. Dann gehe einfach mal davon
aus, dass dies für den Anwendungsfall die beste Lösung ist. Es gint
mehrere templates die beim Deployment automatisch expandiert werden. Du
kannst gerne zeigen, wie man mit mod_vhost_alias das Äquivalauent zu

ProxyFCGISetEnvIf "true" PHP_VALUE "error_log=/path/to/error/log/{NAME}/and/some/more/{substitions}/phperrors"
schreibt. Und es gibt noch mehr nutzerspezifische Settings (env Variablen zB)

[Karl Pflästerer]

Tim Ritberg <t...@server.invalid> writes:

> Am 15.06.22 um 22:28 schrieb Karl Pflästerer:
>>> Man nennt es "bug".
>>>
>>> https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/
>> Ja und? Du verwendest lieber eine alte nicht mehr gewartete Apache
>> Extension (letzte Version 2016) als Apache mit aktuell betreuten
>> Modulen, bei denen man eher davon ausgehen kann, das Bugs gefunden und
>> behoben werden? Verstehe ich nicht.
> Ich merks. Scheint heut nicht dein Tag zu sein.

?? Was soll das? Ich frage nach deiner Motivation ein altes nicht mehr
betreutes Stück Software einsetzen zu wollen. Dies ist ein reales
security Problem.

>> Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
>> gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
>> Trennung strikter sein (mit zB Docker Container kein so großer
>> Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
>> will.
> Feindlich hin oder her, Security per Design, alles mit www-data laufen zu
> lassen ist dumm.
> Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine Rolle
> spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.

Eine Software, an der seit 6 Jahren nicht mehr gearbeitet wurde ist
entweder perfekt (TeX eventuell) oder tot.

[Tim Ritberg]

Am 16.06.22 um 23:51 schrieb Karl Pflästerer:

>
> ?? Was soll das? Ich frage nach deiner Motivation ein altes nicht mehr
> betreutes Stück Software einsetzen zu wollen. Dies ist ein reales
> security Problem.

Das war eine Analogie!

>
>>> Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
>>> gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
>>> Trennung strikter sein (mit zB Docker Container kein so großer
>>> Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
>>> will.
>> Feindlich hin oder her, Security per Design, alles mit www-data laufen zu
>> lassen ist dumm.
>> Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine Rolle
>> spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.
>
> Eine Software, an der seit 6 Jahren nicht mehr gearbeitet wurde ist
> entweder perfekt (TeX eventuell) oder tot.

Dann ist sie perfekt. Oder meinst du, der Debian Maintainer irrt sich? ;-)

Tim

[Tim Ritberg]

Am 16.06.22 um 20:04 schrieb Laurenz Trossel:

>>> Du kannst jedem vhost einen eigenen httpd-Prozess geben. Das hilft im Falle
>>> eines Bugs auch nur begrenzt, wenn alle im selben System laufen. Wer Code
>>> ausführen kann, kann auch uid 0 erreichen.
>> Wie geht das denn?
>
> Local Root Lücken gibt es in jedem System. Das hält einen kompetenten
> Angreifer nicht lange auf.
>

Ich meinte den Teil mit "eigener Prozess".

Tim

[Laurenz Trossel]

On 2022-06-17, Tim Ritberg <t...@server.invalid> wrote:

>>>> Du kannst jedem vhost einen eigenen httpd-Prozess geben.

>> Wie geht das denn?

> Ich meinte den Teil mit "eigener Prozess".

Achso. systemd Units, natürlich.
Für jeden vhost startest du einen httpd mit seiner Config und einem Unix-Socket.

Ein Proxy verteilt dann die vhosts auf die Sockets.

[Tim Ritberg]

Am 14.06.22 um 14:07 schrieb Arno Welzel:

> Nein, tut man nicht. Nicht Apache soll mit einem anderen User laufen,
> sondern PHP. Und letzteres erreicht man, indem man PHP-FPM nutzt und den
> Pool entsprechend konfiguriert, den gewünschten User zu verwenden.
>

Wie sieht das mit der Gruppe aus?
Ich hatte da nobody im Kopf, www-data wäre kontraproduktiv.

Tim

[Tim Ritberg]

Am 14.06.22 um 14:07 schrieb Arno Welzel:
> Nein, tut man nicht. Nicht Apache soll mit einem anderen User laufen,
> sondern PHP. Und letzteres erreicht man, indem man PHP-FPM nutzt und den
> Pool entsprechend konfiguriert, den gewünschten User zu verwenden.
>
Wie sieht das mit der Gruppe aus?

Ich hatte da nogroup im Kopf, www-data wäre kontraproduktiv.


Tim

[Arno Welzel]

Tim Ritberg:

>
> Am 14.06.22 um 16:57 schrieb Arno Welzel:
>>> Ja nee, ja doch!
>>> Also wie sollen sonst jpg und css ausgeliefert werden?
>>
>> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.
> Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle
> Vhosts zugreifen kann.

Kannst Du ein konkretes Angriffsszenario beschreiben, wo das relevant wäre?

Fall 1:

Irgendein PHP-Script hat eine Sicherheitslücke - nicht relevant, da
PHP-FPM selbst nicht als www-data läuft und PHP auch nicht als Modul in
Apache verwendet wird.

Fall 2:

Apache hat einen Bug, der dazu führt, dass man über eine bestimmte URL
aus dem DocumentRoot des virtuellen Hosts ausbrechen kann und die Daten
anderer virtueller Hosts über die Domain zu lesen.

Ja - das wäre theoretisch denkbar. Aber da www-data ohnehin auf Websites
zugreifen darf - was genau würde man damit gewinnen, statt einfach über
die vorgesehene Domain zuzugreifen?


--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Tim Ritberg:

> Am 15.06.22 um 11:18 schrieb Karl Pflästerer:

[...]

>> Also an welche Art von Angriff denkst du?
> Durchhangeln auf andere Vhost. www-data kann ja an alle Installationen.

Ja und? Alle anderen VHosts sind ja ohnehin aufrufbar. Dafür braucht man
keine Lücke mit www-data.

[Arno Welzel]

Tim Ritberg:

[...]

> Man nennt es "bug".
>
> https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/

Und wie hätte da MPM-ITK geholfen?

Zitat:

"According to the Apache team, less-privileged Apache child processes
(such as CGI scripts) can execute malicious code with the privileges of
the parent process."

Der Parent-Prozess ist halt Apache selbst - egal, ob das CGI-Script mit
ITK auf irgendeinen Account eingeschränkt wird oder als www-data läuft.

[Arno Welzel]

Tim Ritberg:

> Am 15.06.22 um 22:28 schrieb Karl Pflästerer:

[...]

>> Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
>> gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
>> Trennung strikter sein (mit zB Docker Container kein so großer
>> Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
>> will.
> Feindlich hin oder her, Security per Design, alles mit www-data laufen
> zu lassen ist dumm.

Nein, es ist der Normalfall.

> Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine
> Rolle spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.

Und der Maintainer von Debian kümmert sich auch darum, dass das Ding
auch irgendwann mit 400-500 Zugriffen pro Sekunde läuft statt nur 40-70?
So eine Anforderung ist nämlich hier deutlich wichtiger, als die
Vermeidung theoretischer Lücken.

[Arno Welzel]

Tim Ritberg:

> Am 14.06.22 um 14:07 schrieb Arno Welzel:
>> Nein, tut man nicht. Nicht Apache soll mit einem anderen User laufen,
>> sondern PHP. Und letzteres erreicht man, indem man PHP-FPM nutzt und den
>> Pool entsprechend konfiguriert, den gewünschten User zu verwenden.
>>
> Wie sieht das mit der Gruppe aus?

Die kann man bei PHP auch angeben. Siehe /etc/php/<version>/fpm/pool.d/,
wo die Konfiguration verwendet wird, wie in
<https://www.php.net/manual/de/install.fpm.configuration.php> beschrieben.

> Ich hatte da nogroup im Kopf, www-data wäre kontraproduktiv.

Nein, einfach eine eigene Gruppe pro User.

[Thomas Hochstein]

Arno Welzel schrieb:

> Aber da www-data ohnehin auf Websites
> zugreifen darf - was genau würde man damit gewinnen, statt einfach über
> die vorgesehene Domain zuzugreifen?

Sehr viele Webseiten enthalten Dateien, die nicht von außen abrufbar sein
sollen oder dürfen. Zum einen können das interne/geschützte Bereiche sein,
zum anderen sind bei Webapplikationen oder CMS regelmäßig Passworte (bspw.
für die dahinterstehende Datenbank) im Quellcode enthalten.

[Tim Ritberg]

Am 21.06.22 um 02:46 schrieb Arno Welzel:

> Und der Maintainer von Debian kümmert sich auch darum, dass das Ding
> auch irgendwann mit 400-500 Zugriffen pro Sekunde läuft statt nur 40-70?
> So eine Anforderung ist nämlich hier deutlich wichtiger, als die
> Vermeidung theoretischer Lücken.
>

Für mich in den Fall nicht.

Tim

[Tim Ritberg]

Am 21.06.22 um 02:39 schrieb Arno Welzel:

>
> Apache hat einen Bug, der dazu führt, dass man über eine bestimmte URL
> aus dem DocumentRoot des virtuellen Hosts ausbrechen kann und die Daten
> anderer virtueller Hosts über die Domain zu lesen.
>
> Ja - das wäre theoretisch denkbar. Aber da www-data ohnehin auf Websites
> zugreifen darf - was genau würde man damit gewinnen, statt einfach über
> die vorgesehene Domain zuzugreifen?

Schon mal mit einem CMS gearbeitet? Was da so alles im DocRoot liegt.
Es ist also kein theoretisches Problem.

Tim

[Tim Ritberg]

Am 21.06.22 um 02:53 schrieb Arno Welzel:

> Die kann man bei PHP auch angeben. Siehe /etc/php/<version>/fpm/pool.d/,
> wo die Konfiguration verwendet wird, wie in
> <https://www.php.net/manual/de/install.fpm.configuration.php> beschrieben.
>
>> Ich hatte da nogroup im Kopf, www-data wäre kontraproduktiv.
>
> Nein, einfach eine eigene Gruppe pro User.

Finde ich unschön, was spricht gegen nogroup?


Tim

[Arno Welzel]

Thomas Hochstein:

Nein, nicht im Quellcode, sondern in einer Konfigurationdatei, an die
man von außen per HTTP(S) nicht herankommt. Und "geschützte Bereiche"
werden üblicherweise vom Webserver geschützt.

Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
die Dateien für den Webserver via www-data lesbar sind.

Beispiel:

<https://wordpress-demo.arnowelzel.de>

Da gibt es natürlich eine Konfigurationsdatei, die für PHP lesbar im
Webspace liegt. Der Name und Pfad dieser Datei ist bei allen
WordPress-Installationen identisch, da WordPress sie ja lesen können
muss, um die Datenbankverbindung etc. zu kennen. Bitte zeige, wie man an
als Angreifer diese Datei herankommt, weil sie für www-data lesbar ist.

Ach ja - PHP hat nur Zugriff auf die Daten des jeweiligen virtuellen
Hosts und CGI-Scripte oder SSI sind nicht möglich.

[Arno Welzel]

Tim Ritberg:

Ja - nicht nur mit einem. Ich hoste aktuell ca. 40 Websites, die sowohl
WordPress wie auch andere CMS nutzen, betreibe mehrere
Nextcloud-Instanzen und Mailserver und bin Maintainer mehrerer Plugins
für WordPress und Nextcloud.

> Es ist also kein theoretisches Problem.

Dann kannst Du sicher ein konkretes Angriffsszenario beschreiben, was
trotz suEXEC und eigener User/Group für PHP in jeder Website etc.
ausnutzbar ist.

[Arno Welzel]

Tim Ritberg:

Was spricht dafür?

[Tim Ritberg]

Am 21.06.22 um 19:49 schrieb Arno Welzel:
> Was spricht dafür?
Nur eine Gruppe und nicht einen Wust. Ausserdem ist nogroup genau dafür da.

Tim

[Tim Ritberg]

Am 21.06.22 um 19:49 schrieb Arno Welzel:

> Dann kannst Du sicher ein konkretes Angriffsszenario beschreiben, was
> trotz suEXEC und eigener User/Group für PHP in jeder Website etc.
> ausnutzbar ist.

Für wärs hiermit?

https://zero.bs/sb-2120-critical-bug-in-apache-httpd-can-lead-to-rce-cve-2021-41773.html

Man sollte also dem Apache-User die Leserechte für die DB-Config nehmen.

Tim

[Arno Welzel]

Tim Ritberg:

> Am 21.06.22 um 19:49 schrieb Arno Welzel:
>> Was spricht dafür?
> Nur eine Gruppe und nicht einen Wust. Ausserdem ist nogroup genau dafür da.

Aber ein "Wust" an Usern ist akzeptabel?

Der User "nobody" und die Gruppe "nogroup" sind für Dienste gedacht, die
*keine* Dateien lesen können sollen. Ein Webserver oder PHP-FPM muss
aber Dateien lesen können und sinnvollerweise hat man dafür einen User
und ggf. eine primäre Gruppe mit dem selben Namen.

Und zum Angriffsszenario "Angreifer hat die Rechte von www-data":

Das ist nur relevant, wenn man einem Nutzer Zugriff auf den Webspace
gibt und er dort auch Scripte mit PHP o.Ä. nutzen darf, die dann mit den
Rechten von www-data auch andere Dateien als die im eigenen Webspace
lesen dürften. Genau das wird aber damit verhindert, dass man PHP selbst
eben *nicht* mit www-data laufen lässt und die Nutzung von CGI etc.
nicht erlaubt.

[Arno Welzel]

Tim Ritberg:

Was ja nicht schwer ist - PHP-FPM läuft mit einem eigenen User und nicht
"www-data" und "www-data" bekommt keine Leserechte auf die relevanten
Dateien.

[Tim Ritberg]

Am 21.06.22 um 21:19 schrieb Arno Welzel:

> Der User "nobody" und die Gruppe "nogroup" sind für Dienste gedacht, die
> *keine* Dateien lesen können sollen. Ein Webserver oder PHP-FPM muss
> aber Dateien lesen können und sinnvollerweise hat man dafür einen User
> und ggf. eine primäre Gruppe mit dem selben Namen.

Für den PHP-Prozess brauche ich aber keine Gruppe. Alle Aktionen laufen
über den User.


Tim

[Laurenz Trossel]

On 2022-06-21, Arno Welzel <use...@arnowelzel.de> wrote:

> Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
> Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
> die Dateien für den Webserver via www-data lesbar sind.

Der Kontext war die Ausnutzung eines Bugs u.a. im (PHP-)Code. Dann kann man
auch die Dateien lesen, die der Webserver normalerweise nicht ausliefert
oder Code nachladen und sich interaktiv umsehen.

Tim scheint besorgt zu sein, daß ein Angreifer zusäzlich auch Dateien aus
anderen vhosts sehen könnte.

Da es in meiner Betrachtung keinen nennenswerten Unterschied zwischen "Code
als www-user42 ausführen" und "Uid 0 erlangen" gibt, sehe ich keine bessere
Methode als die Mountspaces zu trennen. Die vhosts im selben System mit
verschiedenen uids zu betreiben, ist eine Sicherheitsillusion. YMMV.

> Ach ja - PHP hat nur Zugriff auf die Daten des jeweiligen virtuellen
> Hosts

Wie trennst du die vhosts? Ausbruchsicheres chroot?

[Arno Welzel]

Laurenz Trossel:

> On 2022-06-21, Arno Welzel <use...@arnowelzel.de> wrote:
>
>> Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
>> Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
>> die Dateien für den Webserver via www-data lesbar sind.
>
> Der Kontext war die Ausnutzung eines Bugs u.a. im (PHP-)Code. Dann kann man
> auch die Dateien lesen, die der Webserver normalerweise nicht ausliefert
> oder Code nachladen und sich interaktiv umsehen.

PHP läuft aber nicht mit www-data, sondern einem eigenen User.

> Tim scheint besorgt zu sein, daß ein Angreifer zusäzlich auch Dateien aus
> anderen vhosts sehen könnte.

Ja, der der andere geschilderte Bug in Apache mit ausnutzbarer Path
Traversal kann u.U. noch viel mehr Schaden anrichten, als lediglich
Zugriff auf die Daten anderer virtueller Hosts. Wenn so beliebiger Code
ausführbar ist, spielt es letztlich keien Rolle mehr, ob nun der
virtuelle Host mit www-data läuft oder nicht.

> Da es in meiner Betrachtung keinen nennenswerten Unterschied zwischen "Code
> als www-user42 ausführen" und "Uid 0 erlangen" gibt, sehe ich keine bessere
> Methode als die Mountspaces zu trennen. Die vhosts im selben System mit
> verschiedenen uids zu betreiben, ist eine Sicherheitsillusion. YMMV.

Ja, sehe ich ebenso.

>> Ach ja - PHP hat nur Zugriff auf die Daten des jeweiligen virtuellen
>> Hosts
>
> Wie trennst du die vhosts? Ausbruchsicheres chroot?

Jeder PHP-FPM läuft mit eigenem User, der nur auf sein Webroot zugreifen
darf und sonst nichts im System machen darf. Mit einem PHP-Script allein
ist es nicht möglich, da rauszukommen.

Nein, gegen beliebige Bugs, der im System auftreten könnten, hilft auch
das nicht. Genauso wie chroot nicht absolut sicher ist und Container
ebenso wenig. Überall können Fehler drin sein. Man muss am Ende immer
abwägen, wie wahrscheinlich es ist, dass solche Fehler existieren. Am
Ende wird man jedem Benutzer seine komplette eigene VM geben, wenn man
ganz sicher sein will - und auch die ist nicht absolut "ausbruchssicher".

[Arno Welzel]

Tim Ritberg:

Dann trage eben nogroup beim PHP-FPM-Pool ein. Prinzipiell sollte das gehen.

[Tim Ritberg]

Am 22.06.22 um 02:25 schrieb Arno Welzel:

> Dann trage eben nogroup beim PHP-FPM-Pool ein. Prinzipiell sollte das gehen.

Habe ich schon gemacht, bisher keine Probleme damit gesehen.
Mit einer ACL bekommt dann www-data noch Leserechte.

Tim

[Thomas Hochstein]

Arno Welzel schrieb:

> Thomas Hochstein:

> > Sehr viele Webseiten enthalten Dateien, die nicht von außen abrufbar sein
> > sollen oder dürfen. Zum einen können das interne/geschützte Bereiche sein,
> > zum anderen sind bei Webapplikationen oder CMS regelmäßig Passworte (bspw.
> > für die dahinterstehende Datenbank) im Quellcode enthalten.
>
> Nein, nicht im Quellcode, sondern in einer Konfigurationdatei, an die
> man von außen per HTTP(S) nicht herankommt. Und "geschützte Bereiche"
> werden üblicherweise vom Webserver geschützt.

Wieso "nein"? Du wiederholst doch mit anderen Worten, was ich schrieb.

> Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
> Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
> die Dateien für den Webserver via www-data lesbar sind.

Bei korrekter Konfiguration und Fehlerfreiheit des Webservers, PHP und der
darin geschriebenen Anwendungen hat man sehr viele Probleme nicht, ja.

[Arno Welzel]

Thomas Hochstein:

> Arno Welzel schrieb:
>
>> Thomas Hochstein:
>>> Sehr viele Webseiten enthalten Dateien, die nicht von außen abrufbar sein
>>> sollen oder dürfen. Zum einen können das interne/geschützte Bereiche sein,
>>> zum anderen sind bei Webapplikationen oder CMS regelmäßig Passworte (bspw.
>>> für die dahinterstehende Datenbank) im Quellcode enthalten.
>>
>> Nein, nicht im Quellcode, sondern in einer Konfigurationdatei, an die
>> man von außen per HTTP(S) nicht herankommt. Und "geschützte Bereiche"
>> werden üblicherweise vom Webserver geschützt.
>
> Wieso "nein"? Du wiederholst doch mit anderen Worten, was ich schrieb.

Du schreibst, im Quellcode von Dateien wären Passworte vorhanden.

Und ich sagte: nein, genau da sind diese Datene eben *nicht*. Das ist
nicht das selbe. Bei Symfony z.B. liegen die Datenbank-Zugangsdaten in
der Environment-Konfiguration, die *nicht* durch den Webserver
erreichbar ist.

>> Ich sehe immer noch kein Szenario, bei dem ein Angreifer bei korrekter
>> Konfiguration des Webservers an diese Daten herankommen sollte, nur weil
>> die Dateien für den Webserver via www-data lesbar sind.
>
> Bei korrekter Konfiguration und Fehlerfreiheit des Webservers, PHP und der
> darin geschriebenen Anwendungen hat man sehr viele Probleme nicht, ja.

Eben - darum geht es.

Wenn die Anwendung fehlerhaft ist, ist es komplett egal, ob sie mit
www-data läuft oder nicht! Wenn ein Angreifer dadurch z.B. das
Datenbank-Passwort herausfindet, kann er auf die Datenbank zugreifen,
egal welcher User für die Ausführung des Webservers und PHP genutzt
wird. Ebenso kann ein Angreifer bei Erlangung von Schreibrechten
beliebige Malware auf der Website plazieren, egal mit welchem User das
im Einzelfall erfolgt.