Afdrukvoorbeeld
Er is een nieuwe optie bij gekomen.
RDocumentChRoot
Maar wat beteken 'Set chroot directory and the document root inside' nu precies? :huh:
Word hiermee een chroot omgeving voor de gebruiker gemaakt of kan deze alleen zijn map bereiken en niet dieper?
Voor zo ver ik weet zijn er geen problemen met 0.9. Hier draait de module al enige tijd probleemloos in productie.Citaat:
Oorspronkelijk geplaatst door Boyke
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.Citaat:
Oorspronkelijk geplaatst door Rollerscapes
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).
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.Citaat:
Oorspronkelijk geplaatst door wdv
Zijn hier nog ontwikkelingen in? Ik heb namelijk net een test gedaan met mod_ruid2 en krijg dan de volgende fouten:
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.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
Ik heb nog een 2e fout gevonden:
Nu kan dit wel aangepast worden door /var/lib/php5 in je chroot aan te maken.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
En ik kreeg de volgende melding in mijn logs:
Ik weet niet of dit erg is?!Code:warning: `apache2' uses 32-bit capabilities (legacy support in use)
Vreemd, de timezone is normaal gesproken embeded.Citaat:
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
Gebruik je toevallig Debian of Ubuntu?
Dat komt zo te zien omdat je op 64bit werkt, het kan zijn dat libcap niet volledig 64bit is?Citaat:
warning: `apache2' uses 32-bit capabilities (legacy support in use)
Het is een 32bit VM. Dus ik vond het al vreemd...Citaat:
Oorspronkelijk geplaatst door Rollerscapes
Debian Lenny inderdaad. Is dat een bekend probleem dan?
Het is een 32bit VM. Dus ik vond het al vreemd...Citaat:
Oorspronkelijk geplaatst door Rollerscapes
"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 :)
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.Citaat:
Oorspronkelijk geplaatst door Rollerscapes
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.
[ame]http://en.wikipedia.org/wiki/Chroot[/ame]Citaat:
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.
Aha, maar toch is het qua beveiliging wel weer een extra hindernis. En dat is wel handig op een shared server.Citaat:
Oorspronkelijk geplaatst door Rollerscapes
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...
:W: Mijn dank is groot.