Onderwerp: mod_ruid nieuwe ontwikkelingen

Er is een nieuwe optie bij gekomen.
RDocumentChRoot

Maar wat beteken 'Set chroot directory and the document root inside' nu precies?
Word hiermee een chroot omgeving voor de gebruiker gemaakt of kan deze alleen zijn map bereiken en niet dieper?

Oorspronkelijk geplaatst door Boyke

Ik zie dat 0.9 inmiddels ook beschikbaar is? Kan deze beschouwd worden als stable?

Voor zo ver ik weet zijn er geen problemen met 0.9. Hier draait de module al enige tijd probleemloos in productie.

Oorspronkelijk geplaatst door Rollerscapes

Er is een nieuwe optie bij gekomen.
RDocumentChRoot

Maar wat beteken 'Set chroot directory and the document root inside' nu precies?
Word hiermee een chroot omgeving voor de gebruiker gemaakt of kan deze alleen zijn map bereiken en niet dieper?

Exact, RDocumentChRoot is een alternatief voor DocumentRoot waarbij de gebruiker voor de duur van de request wordt opgesloten in een chroot. Na de request wordt de chroot weer ongedaan gemaakt.

Voor de werking zie ook http://www.webhostingtalk.nl/scripti...ml#post1015291

Deze module is nu samengevoegd met mod_ruid2. De chroot functionaliteit wordt overigens alleen ingeschakeld als "RDocumentChRoot" voor komt in de config. Gebruik je de chroot niet dan worden geen extra capabilities actief gehouden en is het een "gewone" mod_ruid2.

Kees, draai jij nog een bepaalde kernel module om te voorkomen dat in geval van een exploit Apache als root zou kunnen draaien? Zo ja, heb je hier meer informatie over?

Dus simpel gezegd kan die gebruiker alleen in zijn eigen chroot werken?
Maar kan hij dan wel bij de /usr/bin mappen komen, of moet je die in de chroot map plaatsen?

Waar ik zelf nog veel hinder van ondervind zijn processes die gestart worden door klanten die de filedescriptors erven van apache en daardoor poort 80 bezet houden waardoor apache zelf op een gegeven moment stopt met werken.

Nu heb ik hier zelf al wat omheengemaakt dus heb er eigenlijk geen last meer van.. Af en toe een mailtje van een webserver die meld dat ie het proces heeft afgeschoten en onder welke userid dat proces draaide ;-)

maar het zou mooi zijn als dit op 1 of andere manier voorkomen kon worden. Is dat iets wat mod_ruid zou kunnen ondervangen?

http://bugs.php.net/bug.php?id=38915

Heeft er geloof ik mee te maken (het is al een tijdje geleden dat ik het uitgezocht heb).

Oorspronkelijk geplaatst door wdv

Kees, draai jij nog een bepaalde kernel module om te voorkomen dat in geval van een exploit Apache als root zou kunnen draaien? Zo ja, heb je hier meer informatie over?

Ik heb de kernel gepached zo dat setuid (en aanverwante functies) alleen van een webuser nog terug kan naar apache en dat apache alleen nog naar een webuser kan. Uiteraard kan dit dan weer alleen als de juiste capabilities zijn gezet.

Zijn hier nog ontwikkelingen in? Ik heb namelijk net een test gedaan met mod_ruid2 en krijg dan de volgende fouten:

Code:

Fatal error: strtotime() [<a href='function.strtotime'>function.strtotime</a>]: Timezone database is corrupt - this should *never* happen! in /web/wp-includes/comment.php on line 1896

Deze fout krijg ik niet als ik RDocumentChRoot niet gebruik. Maar dit is juist een hele mooie optie om de mensen echt compleet af te sluiten. Is dit op te lossen? Door die timezone data ergens anders vandaan te halen ofzo? En ik weet niet of er meer van dit soort problemen kunnen ontstaan.

Ik heb nog een 2e fout gevonden:

Code:

Warning: session_start() [function.session-start]: open(/var/lib/php5/sess_293da7daab0cdcf12a818d7a68fb8ced, O_RDWR) failed: No such file or directory (2) in /web/index.php on line 2

Nu kan dit wel aangepast worden door /var/lib/php5 in je chroot aan te maken.

En ik kreeg de volgende melding in mijn logs:

Code:

warning: `apache2' uses 32-bit capabilities (legacy support in use)

Ik weet niet of dit erg is?!

Fatal error: strtotime() [<a href='function.strtotime'>function.strtotime</a>]: Timezone database is corrupt - this should *never* happen! in /web/wp-includes/comment.php on line 1896

Vreemd, de timezone is normaal gesproken embeded.
Gebruik je toevallig Debian of Ubuntu?

warning: `apache2' uses 32-bit capabilities (legacy support in use)

Dat komt zo te zien omdat je op 64bit werkt, het kan zijn dat libcap niet volledig 64bit is?

Oorspronkelijk geplaatst door Rollerscapes

Vreemd, de timezone is normaal gesproken embeded.
Gebruik je toevallig Debian of Ubuntu?

Het is een 32bit VM. Dus ik vond het al vreemd...
Debian Lenny inderdaad. Is dat een bekend probleem dan?

Oorspronkelijk geplaatst door Rollerscapes

Dat komt zo te zien omdat je op 64bit werkt, het kan zijn dat libcap niet volledig 64bit is?

Het is een 32bit VM. Dus ik vond het al vreemd...

"Debian Lenny inderdaad. Is dat een bekend probleem dan?"
Niet helemaal precies, maar bepaalde versies van Debian (en bijna alle versies van Ubuntu) zijn voorzien van een patch welke er voor zorgt dat de timezone database van het OS zelf word gebruikt. (Domheid ten top, meerdere mensen hebben hier al over geklaagd).

En omdat die op een andere locatie staat (/var/share als ik het goed heb ), kan PHP hem in chroot-modus niet lezen.
Normaal is de timezone-db embeded, dus geen apart bestand.

Je hebt kans als je Fileinfo probeert te gebruiken je tegen een zelfde soort probleem aanloopt. Omdat die ook een los bestand moet inlezen (normaal gedrag overigens).

Daarom is chroot niet altijd even handig.
Maar is er geen mogelijkheid om meerdere locaties aan te geven die mogen worden benaderd vanuit de chroot?
Edit: Ja dus

Oorspronkelijk geplaatst door Rollerscapes

Daarom is chroot niet altijd even handig.
Maar is er geen mogelijkheid om meerdere locaties aan te geven die mogen worden benaderd vanuit de chroot?

Nee je kan alleen je chroot dir aangeven; bijvoorbeeld /home/ en dan als 2e directorties je DocRoot ten op zichte van je chroot directory. Ik zou dus moeten weten wat daar allemaal in moet staan, om een complete chroot te maken.

Alleen wil ik chrooten per domein van een user, dus de chroot in /home/user/web/<domein>/ en dan zou ik dus voor elk domein die bestanden erin moeten zetten en up-to-date houden. Lastig, terwijl dit wel een hele mooie functie is om alles gescheiden te houden.

De chroot techniek zelf was ook nooit bedoeld als beveiligingsmaatregel.

The chroot system call was introduced during development of Version 7 Unix in 1979, and also added to BSD by Bill Joy on 18 March 1982 — 17 months before 4.2BSD was released — in order to test its installation and build system.

[ame]http://en.wikipedia.org/wiki/Chroot[/ame]

Oorspronkelijk geplaatst door Rollerscapes

De chroot techniek zelf was ook nooit bedoeld als beveiligingsmaatregel

Aha, maar toch is het qua beveiliging wel weer een extra hindernis. En dat is wel handig op een shared server.
Alleen kon je uit een chroot komen geloof ik als je daarin root had verkregen ofzo... maar goed, dat is toch weer een extra hindernis.

Ik heb een paar dagen terug mod_ruid2 0.9.3 op sourceforge gezet. Na een paar versies waarin niet zo heel veel spannends is aangepast is dit er weer een die het melden waard is. In deze versie is een belangrijke bug gefixt in de chroot functie. Mocht je RDocumentChroot willen gebruiken dan is een upgrade absoluut noodzakelijk, aangezien de chroot in mod_ruid2 niet overweg kon met subrequests van mod_rewrite.

Voor de liefhebbers: http://sourceforge.net/projects/mod-ruid/files/latest/

Veel plezier er mee...

Mijn dank is groot.