Onderwerp: mod_suid(2)/mod_ruid ervaringen en tips

Ik heb hem vandaag geinstalleerd
Man dat noem ik nog is snelheid

Code:

ldd mod_ruid.so
        /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40004000)
        libcap.so.1 => /lib/libcap.so.1 (0x40012000)
        libc.so.6 => /lib/libc.so.6 (0x40016000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Edit: libc is bijgewerkt, maar zonder mijn mede weten (Opzich geen probleem, nu werkt nmap te minsten weer)

Oorspronkelijk geplaatst door XBL

B (de gebruiker met het eigen brakke scriptje heeft dikke pech).

Ben ik dan de enige die denkt dat dit echt niet echt de juiste oplossing is?

Stel je even voor, je hebt wat drukke sites op je server staan en er komt een bug uit voor een van de gebruikte CMS systemen (of gewoon een fout in eigen ontwikkelde code). Dan kan de persoon die dit lek misbruikt even leuk wat code toevoegen aan een van deze sites en bv. iedereen op spyware trakteren (en ja dan lijkt het of het van een trusted bron komt). Afrader dus...

Optie zou zijn elke user een ftp account te maken (bv username) en dan een username_proc voor de ruid.


Laat even horen hoe jullie erover denken...

(sorry voor late reactie, was er vandaag mee bezig voor een klant).

Dan kan je via de FTP/SSH nog steeds niet de files beheren die je via PHP/Perl aanmaakt.

Dat is nou een groot voordeel van een module als mod_ruid.

Uit dat zicht is het wel boeiend, dat klopt zeker.

Maar het potentiele security probleem is zeker niet klein...

Niet groter dan alles onder user www-data en varianten draaien, wat zo'n beetje heel veel hosters doen, namelijk erg veel kleiner.

Oorspronkelijk geplaatst door luser

Uit dat zicht is het wel boeiend, dat klopt zeker.

Maar het potentiele security probleem is zeker niet klein...

Laat het nou net zijn dat dát het gene is wat de meeste klanten willen.

Dagelijks op de helpdesk uitleggen dat mensen files die via PHP aangemaakt zijn moeten verwijderen via PHP en dat het niet kan via de FTP komt je na enkele weken ook de keel uit.

Het zijn keuzes die je soms moet maken. Als het kan draai ik de PHP onder een andere gebruiker dan waar de files van zijn, maar dan moet je de applicatie wel kennen en een webmaster hebben met verstand van zaken.

De meeste mensen die Joomla installeren hebben dat vaak niet en die snappen er dan ook helemaal niets van.

Dan is het dus echt een stuk handiger om mod_ruid te draaien. Dat die sites dan eventueel gedefaced worden is echt een verantwoordelijkheid van de webmaster. Ik ben van mening dat je als hoster moet hosten en je niet moet bemoeien met de content (zolang het legaal blijft), dat is iets waar de klant voor moet zorgen.

Als je een goed ontwikkeld security concept hebt op je servers moet je echt niet bang zijn dit onder de nobody/apache/www/... user te draaien. Heeft weinig zin dan de vieze dingen naar de useraccount te verplaatsen als het toch mogelijk blijft.

Wido heeft een punt, zeker als je met veel (shared) hostingklanten zit. Ik werk gelukkig uit een ander standpunt.

Sorry als ik je niet helemaal begrijp luser
Maar bedoel je nou dat mod_ruid slecht is, of juich je het juist toe?

Oorspronkelijk geplaatst door luser

Als je een goed ontwikkeld security concept hebt op je servers moet je echt niet bang zijn dit onder de nobody/apache/www/... user te draaien. Heeft weinig zin dan de vieze dingen naar de useraccount te verplaatsen als het toch mogelijk blijft.

Wido heeft een punt, zeker als je met veel (shared) hostingklanten zit. Ik werk gelukkig uit een ander standpunt.

Daarom, je kan niet alles over één kam scheren.

Wij hebben ook een aantal grotere klanten die managed clusters afnemen en daarop draaien we geen mod_ruid. Wij kennen hun applicatie en zij hebben goede programmeurs die er mee overweg kunnen dat de FTP een andere gebruiker is dat de PHP.

Maar als je met veel shared hosting klanten zit, dan is mod_ruid erg fijn.

Is er ergens ook een fatsoenlijke guide voor de install van mod_ruid op een DA server?

Je moet eerst zorgen dat je Apache 2 draait, daarna doe je (Debian):

Code:

apt-get install libcap-dev
cd /usr/src
wget http://websupport.sk/~stanojr/projects/mod_ruid/mod_ruid-0.6b.tar.gz
tar -xzf mod_ruid-0.6b.tar.gz
cd mod_ruid-0.6b
/usr/sbin/apxs -a -i -l cap -c mod_ruid.c

Voeg hierna in je httpd.conf het volgende toe naar User/Group:

Code:

# mod_ruid
RMode config
RUidGid apache apache

Nu gaan we de vhosts openen:

Code:

cd /usr/local/directadmin/data/templates
cp virtual_host2* custom/
cd custom
nano virtual_host2*

Comment daar de SUExec regel, en voeg toe:

Code:

RMode config
RUidGid |USER| |GROUP

Je kan het ook heel simpel doen:

Code:

cd /usr/local/directadmin/data/templates/custom
wget http://crew.pcextreme.nl/files/linux/util/directadmin/da_vhosts_templates_apache2_mod_ruid.tar.gz
tar -xzf da_vhosts_templates_apache2_mod_ruid.tar.gz
rm da_vhosts_templates_apache2_mod_ruid.tar.gz
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

Voila, je draait nu mod_ruid met DA

Toppie! ik zal ff kijken hoe ik dat naar centos omzet.

Gaat op CentOS precies het zelfde, alleen moet je dan zorgen dat je libcap-dev via een RPM (yum ofzo?) binnen haalt.

Oorspronkelijk geplaatst door Rollerscapes

Sorry als ik je niet helemaal begrijp luser
Maar bedoel je nou dat mod_ruid slecht is, of juich je het juist toe?

Hangt van de applicatie af zoals Wido ook al vertelde. Wou gewoon even aantonen dat je niet zomaar mod_ruid mag gaan gebruiken.

EDIT: en dat door het gebruik ervan niet alles default op veilig gaat.

Oorspronkelijk geplaatst door luser

en dat door het gebruik ervan niet alles default op veilig gaat.

duh...