PDA

Bekijk Volledige Versie : mod_suid(2)/mod_ruid ervaringen en tips



XBL
12/09/06, 22:38
Beste,

De laatste tijd ben ik mij verder aan het verdiepen aan het op systeem niveau beveiligen van servers, met name tegen malafide scriptjes van gebruikers. En dan voornamelijk de algehele server en de andere gebruikers beschermen (de gebruiker met het eigen brakke scriptje heeft dikke pech).

Er bestaan natuurlijk zat oplossingen die, met name, als module van apache draaien (denk aan mod_security en mod_suphp). Maar deze doen slechts een klein dingetje.

Kortom, wil je je volledige Apache installatie beschermen beland bij zaken als mod_suid en mod_ruid (immers, de hele vhost draait dan als de user en niet enkel php). Voordeel is dat de gebruiker op die manier _nooit_ meer kan als de gebruiker 'normaal' kan (je kan dus veilig system(); toelaten, in principe). Voorwaarde is wel weer dat de gebruiker behoorlijke limitaties krijgt middels rsbac of selinux.

Een zoektocht naar de genoemde mod_suid en mod_ruid levert absoluut niet veel op. Het blijkt toch over het algemeen dat je veel zelf maar moet gaan uitvogelen. Ook hier op het forum kom ik meestal alleen Wido tegen t.bloo die blijkbaar actief gebruik maken van voorgenoemde mod_'s.

Nu is toch eigenlijk mijn vraag of er hier mensen zijn die meer kunnen vertellen over deze zaken. Bijvoorbeeld documenten noemen waar ze veel aan hebben gehad voor het configureren van rsbac of selinux (met name gericht op webservers met php en dergelijke). Ook ben ik benieuwd naar het wezenlijke verschil tussen mod_suid en mod_ruid; en ook hier misschien goede documentatie die hen op weg heeft geholpen (of zelf wat willen schrijven?).

Binnenkort zal ik eens op een testserver hier mee gaan experimenteren (eerst mod_suid/mod_ruid zodra ik de wezenlijke verschillen weet) en daarna ook eens verder verdiepen in rsbac of selinux (ook hier geld eigenlijk: wat zijn de verschillen?)).

Hopelijk kan uit dit topic wat goede informatie ontstaan voor anderen die hun server met deze hulpmiddelen willen beveiligen. Alvast bedankt voor het meedenken!

Jochem

Wido
12/09/06, 23:47
Jup, daar ben ik dan!

mod_suid maakt gebruik van de traditionele setuid() functies, wat je hiermee dus krijgt is dat een child van Apache maar 1 request kan afhandelen (desnoods nog iets meer door KeepAlive) en daarna gaat hij dood. Terugschakelen naar root of een andere gebruiker is immers niet mogelijk.

mod_ruid werkt via Linux Capabilities, je master-proces van Apache draait namelijk altijd als root (dat moet om aan poort 80 te binden).

Doordat dat proces als root draait kan deze via Capabilities rechten toekennen aan een child om van uid/gid te wisselen.

Is deze child klaar? Dan gaat hij weer terug naar nobody/nogroup (wat jij ook instelt).

Wij zijn nu juist van mod_suid (Apache 1.3) aan het overgaan naar mod_ruid (Apache 2.0) en ik moet zeggen dat het me prima bevalt.

Ik heb het ook al op diverse DirectAdmin systemen toegepast, ook zonder problemen.

De performance van mod_ruid vs mod_suid is ook gigantisch, ik merkte een flinke performance winst met mod_ruid.

RSBAC en mod_ruid is lastig, wij hebben om die reden ook betaalde support bij RSBAC genomen om het geheel werkend te krijgen, de documentatie van RSBAC strekt niet ver genoeg om het goed werkend te krijgen.

mind
13/09/06, 01:03
Als je met mod_ruid gaat spelen, laat er dan wel ff de bijgesloten patch op los. Standaard zitten er een paar grappen (lees bugjes) in die hele interssante effecten kunnen geven. Zo heeft een child tijdens de eerste request die het verwerkt nog de groepen van het parrent process. Ook kan bij het gebruik van de "stat" mode een bestand, onder bepaalde omstandigheden, met een random user/group uitgevoerd worden.

Ik ben overigens wel benieuwd of er door anderen nog meer aan mod_ruid gepatched is....

RayManZ
13/09/06, 01:04
ik heb nu mod_ruid redelijk draaiend op mijn directadmin server maar 1 probleem waar ik steeds tegen aanloop zijn de programma's die zich bevinden in /var/www/html

Dat zijn dus: phpMyAdmin, Webmail en Squirrelmail.

Deze werken na het installeren van mod_ruid niet lekker en ik krijg ze eigenlijk ook niet goed meer werkend... Misschien dat jij de oplossing hiervoor weet Wido?

Wido
13/09/06, 01:06
Je bedoeld zeker op het moment dat iemand /webmail achter zijn domein tikt?

Dat komt doordat het Alias'en zijn in Apache. Een oplossing daarvoor heb ik ook nog niet.

RayManZ
13/09/06, 01:08
Dat bedoel ik inderdaad... Hoe heb jij dit nu opgelost? phpmyadmin werkt zonder problemen. Helaas webmail niet...

gjtje
13/09/06, 01:11
Mod_ruid werkt prima, vreemd dat het schijnbaar nog weinig gebruikt wordt. Behalve dat het veiliger is, is het ook een stuk makkelijker. Geen gezeur meer met bestanden die van apache zijn i.p.v. de gebruiker en g+s moeten zetten en weet ik veel wat voor gepruts er allemaal plaatsvindt.

Draai de webmail/phpmyadmin e.d. als een subdomein van je hosting bedrijf. Het is een dienst die je aanbiedt als bedrijf lijkt me dan prima het zo op te lossen. Klanten kunnen ook hun eigen phpmyadmin of webmail installeren.

RayManZ
13/09/06, 01:14
inderdaad een goed idee... Gewoon een redirect maken :D ik ga hier even mee aan de slag en kijken of het ook werkt. Tnx

Wido
13/09/06, 01:15
Dat bedoel ik inderdaad... Hoe heb jij dit nu opgelost? phpmyadmin werkt zonder problemen. Helaas webmail niet...Mensen vertellen via een bepaalde URL de webmail te bezoeken.

Hostname-van-de-server/webmail

Daarnaast is mod_ruid ook nog eens handig als er weer rare shit in je /tmp staat, weet je direct van wie het is :)

Ook botjes en andere rare scripts, zijn zo te vinden :)

mind
13/09/06, 01:20
Je bedoeld zeker op het moment dat iemand /webmail achter zijn domein tikt?

Dat komt doordat het Alias'en zijn in Apache. Een oplossing daarvoor heb ik ook nog niet.

Er zijn twee oplossingen voor
1. Voor elke virtual host een eigen php session en upload dir geven met als owner de user en group van die virtual host. (ik weet niet of dat werkt in combinatie met DA)

2. Mod proxy gebruiken voor de webmail, levert wel wat overhead op maar dan worden de bestanden gewoon door apache uitgevoerd en is het probleem ook verholpen.

RayManZ
13/09/06, 01:51
Wat ik nu heb gedaan is vrij simpel.

squirrelmail heb ik als map gemaakt in /var/www/html ipv een symbolic.
in deze map zit een index.php welke via een header(); redirect naar mijn webmail. servertje@mijndomeinnaam.nl/squirrelmail-versie

Deze kon ik wel netjes chownen op mijn username en chmodden op 700 en 600 zonder dat alles stuk ging.

Hetzelfde deed ik voor /webmail alleen redirect deze ook naar squirrelmail. Nu kan men dus gewoon bij zijn domeinnaam /webmail of /squirrelmail doen en toch netjes webmailen.

Bedankt voor de oplossing!

XBL
13/09/06, 08:22
Bedankt Wido voor de uitleg van het verschil tussen mod_suid/mod_ruid. Ik kon overigens op de site van rsbac niets vinden over betaalde support; bij wie nemen jullie dat af? En wat moet zoiets ongeveer kosten?

@anderen: Draaien mensen die gebruik maken hier van mod_ruid zonder rsbac of selinux? Hoe hebben jullie dan de normale gebruikers dicht getimmerd? Over mod_suid hoor je immers wel eens spookverhalen (misschien dat mod_ruid, samen met de door mind genoemde patch (hoezo zit dit niet standaard in de de mod?) net zo veilig is als een gewoon apache proces?).

Jochem

Mikey
13/09/06, 10:21
Je bedoeld zeker op het moment dat iemand /webmail achter zijn domein tikt?

Dat komt doordat het Alias'en zijn in Apache. Een oplossing daarvoor heb ik ook nog niet.

Hetzelfde probleem had ik met suphp, je moet de virtualhost gebonden op het ip ook toekennen aan een gebruiker en een groep, chownen naar de betreffende gebruikers. Haal uit de httpd.conf de aliases weg en maak in de templates een redirect 301 aan op |ip|/webmail . Op die manier gaat hij uit de omgeving van de client en springt naar de juiste gebruiker / group om toch webmail fatsoenlijk te kunnen runnen.

bigall
13/09/06, 10:59
@XBL
Wij gebruiken mod_ruid zonder selinux of rsbac.
De mod lijkt dan overigens alleen effect te hebben wanneer je alle directories en bestanden, die toegangelijk zijn voor apache, chmod op 700.

Ook krijg ik geen nette 403 forbidden, maar lelijke php foutmeldingen in de zin van "failed to open stream: Permission denied".

Tevens werken de frontpage server extensies niet meer, omdat deze wordt uitgevoerd als apache:root. Ik heb nog geen manier kunnen vinden om de frontpage extensies werkend te krijgen.

Zijn er misschien meer mensen die ook te maken hebben met deze "problemen", of is dit gewoon een configuratiefout van mij?

gjtje
13/09/06, 11:06
Je krijg geen 403 omdat het geen 403 is maar een 500. Het zal apache een worst wezen wat een script doet, zolang de bezoeker de pagina maar mag openen. Als het script niet toegankelijk is krijg je een 403, anders niet.

chmod 750 werkt ook tenzij je directories met groep user aanmaakt. Maar het is vrij normaal om directories waar niemand anders dan de eigenaar in hoeft te zijn met 700 te chmodden.

bigall
14/09/06, 00:38
Is er iemand die de frontpage server extensions, in combinatie met directadmin en mod_ruid werkend heeft?

Zijn er nog andere gebruikers van mod_ruid die hun ervaringen graag willen delen? Ik vind de support van de mod_ruid website namelijk errug minimaal.

RayManZ
14/09/06, 00:42
frontpage hier gewoon uit staan. Die rommel wil niemand :p

Ik heb tevens een nieuw probleem:

ipadres/~username werkt nu niet meer...

Nu heb ik dat wel weer werkend gekregen. Alleen de sessies die in /tmp staan krijg ik een permission denied op. iemand een oplossing hiervoor?

Keenondots
14/09/06, 10:36
Wat wij hebben draaien om de sessies goed weg te kunnen schrijven:

RMode config
RUidGid customer_username customer_username
RGroups apache webadmin

En een /var/lib/php/session met de volgende rechten:

drwxrwx--- 2 root apache 114K Sep 14 09:33 /var/lib/php/session/

De individuele sessies zien er als volgt uit:

-rw------- 1 customer_username customer_username ... sess_vhpg81...

Includen van PHP libraries (o.a. PEAR) is dan ook veel eenvoudiger.

klasje.be
14/09/06, 17:04
/apachedir/bin/apxs -a -i -l cap -c mod_ruid.c
=> op onze server staat geen apxs, kan ik deze mod ook gewoon installeren door in httpd.conf deze extra regel te zetten?:
LoadModule mod_ruid modules/mod_ruid.c
Neen zeker, want je hebt een .so bestand nodig...
En iets van libcap... (libcap-1.10-20 , rpm -q libcap)
Hoe kan ik alsnog dit installeren dan?

Systeem: CentOs via clarkconnect
Apache 2 handler

RayManZ
14/09/06, 17:08
directadmin cp?

doe eens locate apxs? natuurlijk eerst updatedb doen zodat alle bestanden erin staan. Kan even duren.

klasje.be
14/09/06, 17:10
[root@server /]# locate *apxs*
/usr/webconfig/bin/apxs

[root@server /]# /usr/webconfig/bin/apxs -a -i -l cap -c mod_ruid.c
apxs:Error: /tmp/cc-webconfig-engine-3.2-build/usr/webconfig/bin/httpd not found or not executable

Geen DA, wel webmin, virtualmin, usermin, clarkconnect

WI-Hosting
14/09/06, 17:24
Wij zijn ook aan het kijken naar de combinatie: mod_ruid + DA.

Ik vraag me wel af, wat is het verschil tussen mod_ruid en mod_suPHP?
Want ik hoor veel goede verhalen (security wise en niet performance wise) over suPHP, maar die vreet wel load als een 5 gangen maaltijd..

Enige ervaringen ermee?

gjtje
14/09/06, 17:38
mod_suphp gebruikt de cgi versie van php.

XBL
15/09/06, 08:15
En bij mod_ruid wordt, afaik, alles uitgevoerd onder de gebruiker (dus ook aangevraagde html paginaatjes). Daarnaast kan je vervolgens gewoon de standaard versies van, bijvoorbeeld, php gebruiken wat weer prettig is voor bepaalde controle panelen (met name bij het updaten en dergelijke) en ook voor de performance weer beter is. Je kan immers zelf bepalen hoe je de mod gebruikt (bij PHP inderdaad het verschil tussen cgi/cli voor PHP wat performance-wise een verschil oplevert).

Jochem

gjtje
15/09/06, 09:25
Op een server ben ik trouwens over gestapt op mpm-itk, welke hetzelfde lijkt te doen, alleen dan zonder extra module. ;)

quart
15/09/06, 12:25
Wij zijn ook wel geinteresseerd in het gebruiken van mod_ruid. Weet iemand meer van d e ontwikkelaar van deze module? Ik zie namelijk dat de laatste versie (0.6) van augustus 2005 is. Wordt er nog door anderen aan doorontwikkeld? Ik ben een beetje huiverig voor het gebruiken van een niet onderhouden module ...
Is er iemand die daar meer van weet?

t.bloo
15/09/06, 13:12
tja, ik heb de source code bekeken en het stelt echt geen zak voor, er komt een request binnen en dat stuur je door naar de linux kern. daar valt weinig aan te onderhouden als er niets veranderd op dat gebied toch?

ik gebruik dagelijks 100den van die programma's die niet meer verder ontwikkeld worden, denk aan ls, cd, pwd, cp...

quart
15/09/06, 13:23
Het stelt idd weinig voor.. ls cd pwd etc worden nog wel degelijk onderhouden trouwens, zie http://savannah.gnu.org/projects/coreutils/

liber!
15/09/06, 13:39
Op een server ben ik trouwens over gestapt op mpm-itk, welke hetzelfde lijkt te doen, alleen dan zonder extra module. ;)
Wat zou nu de beste performance (en beveiliging vooral vd parent) geven? mod_ruid of mpm-itk?

gjtje
15/09/06, 13:46
Zal ik van het weekend eens testen, probleem dat we met mod_ruid hadden op die server was dat apache reload niet werkte maar resulteerde in een hangende apache, zonder mod_ruid is dat over.

mpm-itk wordt overiges niet ondersteund (qua support) maar goed, veel ondersteuning voor mod_ruid is er ook niet. ;)

mind
15/09/06, 15:15
tja, ik heb de source code bekeken en het stelt echt geen zak voor, er komt een request binnen en dat stuur je door naar de linux kern. daar valt weinig aan te onderhouden als er niets veranderd op dat gebied toch?
Ik geloof dat je nu toch echt even de begrippen onderhoud en ontwikkeling door elkaar aan het halen bent. Onderhoud aan software is altijd nodig en zo ook bij mod_ruid. De originele source bevat een aantal bugs, waarvan er 2 gefixt worden door mijn patch aan het begin van dit topic. Hoogst waarschijnlijk zitten er nog wel een paar in, maar die heb ik nog niet kunnen vinden.

Op zich vind ik het wel vreemd dat ik (prutser eerste klas) dit soort problemen moet ontdekken. Blijkbaar wordt er nog steeds te veel software "blind" toegepast en gaat men er te veel van uit dat er geen bugs in zitten.

Mijn motto is dan ook: stap 1 op het pad van de beveiliging is argwaan

Wido
16/09/06, 22:39
Voor de gene die Ubuntu/Debian draaien en hun Apache hebben geïnstalleerd via apt-get, ik heb een .deb pakketje wat je kan installeren waardoor je direct gebruik kan maken van mod_ruid

Voeg aan je sources.list toe:

deb http://pcx.apt-get.eu/debian sarge unofficial

Hierna kan je "wscp-libapache2-mod-ruid" installeren via apt-get.

liber!
17/09/06, 14:38
Voor de gene die Ubuntu/Debian draaien en hun Apache hebben geïnstalleerd via apt-get, ik heb een .deb pakketje wat je kan installeren waardoor je direct gebruik kan maken van mod_ruid

Voeg aan je sources.list toe:

deb http://pcx.apt-get.eu/debian sarge unofficial

Hierna kan je "wscp-libapache2-mod-ruid" installeren via apt-get.
Als je wil maak ik er ook een amd64 versie voor.

Sander-
17/09/06, 16:04
Voor de gene die Ubuntu/Debian draaien en hun Apache hebben geïnstalleerd via apt-get, ik heb een .deb pakketje wat je kan installeren waardoor je direct gebruik kan maken van mod_ruid

Voeg aan je sources.list toe:

deb http://pcx.apt-get.eu/debian sarge unofficial

Hierna kan je "wscp-libapache2-mod-ruid" installeren via apt-get.

heb je hierna nog veel configuratieproblemen? Zijn er goede tuts etc die makkelijk te volgen zijn hiervoor?

wdv
17/09/06, 16:40
Wat voor load verhoging moet ik verwachten van deze modules? Ik weet bijvoorbeeld van suPHP dat die enorm is.

Sander-
17/09/06, 16:46
The following packages have unmet dependencies.
wscp-libapache2-mod-ruid: Depends: libcap2 but it is not installable
E: Broken packages


Klopt het dat libcap2 niet in de standaard repos zit? (testing)

Wido
18/09/06, 12:40
The following packages have unmet dependencies.
wscp-libapache2-mod-ruid: Depends: libcap2 but it is not installable
E: Broken packages


Klopt het dat libcap2 niet in de standaard repos zit? (testing)Alles wat ik maak is voor stable.

In testing zit die libcap2 inderdaad niet.

@ liber!, die ga ik binnenkort nog zelf maken.

configureren gaat erg makkelijk.

Je moet mod_ruid.conf in /etc/apache/mods-available even aanpassen (standaard values moeten voldoen in principe)

Daarna doe je in elke virtual host:

RMode config
RUidGid <user> <group>

@ wdv, zo ver ik weet bijna geen load extra, de systemen waar ik het op draai hebben nog steeds een zeer lage load.

Stefan Mensink
18/09/06, 13:05
Let op dat je wel de functie dl in je disable_functions moet zetten als je mod_ruid gebruikt, omdat een user anders via een exploit kan su'en. De functie dl is toch deprecated, dus het lijkt me goed te doen die af te zetten.

Meer info hierover in deze thread (http://www.webhostingtalk.nl/hosting-software-en-overige-controle-panelen/74107-apache-per-user.html) (met dank aan Maxnet voor de testcode).

Wido
18/09/06, 13:06
Daarnaast zou ik ook je php compilen met: --disable-posix

gjtje
18/09/06, 13:07
Welke MPM gebruiken jullie i.c.m. met mod_ruid ?
Had nu weer een server die hangt bij shutdown/reload en mod_ruid geinstalleerd.

SebastiaanStok
20/09/06, 10:35
mod_suphp heeft inderdaat performance problemen :(
Paginas laden langzamer dan normaal met libphp5

Ik ga vandaag even op de test server proberen met mod_ruid :)
Ben benieuwt.

O als ik hem heb geinstalleerd gaat hij lopen zeuren dat libcap niet is geinstalleerd :mad: Terwijl die wel gewoon aanwezig is :huh:

En nu nog leuker, laat ik dan maar proberen met een oude versie en nu doet hij het helemaal niet meer :eek: Dus nu heb ik de kernel op me test bak verziekt...

Wat hebben jullie voor tips?

O als ik hem heb geinstalleerd gaat hij lopen zeuren dat libcap niet is geinstalleerd :mad: Terwijl die wel gewoon aanwezig is :huh:

En nu nog leuker, laat ik dan maar proberen met een oude versie en nu doet hij het helemaal niet meer :eek: Dus nu heb ik de kernel op me test bak verziekt...

Wat hebben jullie voor tips?

He ? Ik plaatje een reactie en staat hij bij die ene :huh:

Oke na een nieuwe versie te hebben geinstalleerd werkt het gelukig weer, hij compileerd te minsten...

SebastiaanStok
20/09/06, 18:25
Oke omdat apxs vreemd genoeg geen so files doe ik ze zelf linken en was ik -l cap vergeten...
Het werkt nu weer, wel snel :D Alleen krijg ik geen php foutmelding als ik geen toegang heb :huh:

rayden
21/09/06, 01:29
Het nadeel van suPHP is inderdaad dat het een fukkin performance hog is, eerder werd gesteld dat het kleine impact heeft'. Nou ik kreeg gelijk van normaal van een load van 0.50 naar dik boven de 5.xx. 'Kleine impact' :/

Ik ga binnenkort weer eens experimenteren met de mod_suid voor de Apache 1.3.x gebruikers onder ons en een HOWTO publiceren, ben nu al in gesprek met de developer over bepaalde opties enz.

wdv
21/09/06, 01:59
@rayden, keep me posted met je ervaringen

SebastiaanStok
21/09/06, 10:36
Kan iemand mij een voorbeeld geven waarom ik: system(), proc_open(), exec() moet uitschakkelen?

Als ik deze uitschakelt dan werkt phpsysinfo niet meer :o

warlock
21/09/06, 11:34
Kan iemand mij een voorbeeld geven waarom ik: system(), proc_open(), exec() moet uitschakkelen?

Als ik deze uitschakelt dan werkt phpsysinfo niet meer :o

Het zijn functies om systeem commandos uit te voeren.... disablen hoeft niet maar ben er wel zeker van dat er geen remote include errors in je script zitten die deze functies kunnen uitvoeren, pas dan kan het riskant worden.

wat is een voorbeeld : <? system("nc -l -e /bin/sh -p 31337"); ?> bv.

MvG.

Jan van de Rijt.

SebastiaanStok
21/09/06, 12:38
Oke dus wel onderstuinnen maar ook de moggelijkheid houden dit voor bepaalde mensen uit te schakkelen?

quart
21/09/06, 16:45
Ik zit met een vreemd probleem met mod_ruid : Alles werkt correct, alleen wanneer ik de directories op 700 chmod, dan krijg ik een 403. Als ik de directories naar 755 chmod gaat het wel goed. De bestanden kan ik wel met permissies 600 laten staan. De webserver draait ook onder de user die ik heb aangegeven in de config van de vhost. De machine is een debian xen virtuele host, met op de dom0 Debian unstable amd64 en op de domU Debian sarge AMD64. Zou het met Xen te maken kunnen hebben? Of heeft iemand anders een goede tip?

RayManZ
25/09/06, 21:07
IK heb een CGI probleem... Iemand een idee hoe ik dit oplos?

ik zie dit in mijn suexeclog

[2006-09-25 20:03:19]: user mismatch (sga instead of apache)

SebastiaanStok
25/09/06, 22:12
Dan zal je suexec moeten uitschakelen :)

RayManZ
25/09/06, 22:17
Hoe fix ik dat met directadmin :S

Wido
27/09/06, 12:06
Zou iedereen die mod_ruid draait het volgende willen doen?


shell> ldd /usr/lib/apache2/modules/mod_ruid.so
libcap.so.2 => /lib/libcap.so.2 (0xb7fe7000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7eb1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)


Uiteraard het pad aanpassen naar je eigen mod_ruid.so

Ik merk namelijk de laatste tijd dat op een van mijn servers Apache soms segfault en daardoor een witte pagina toont.

Nu weet ik niet of dit aan mod_ruid ligt, maar ik wil zo veel mogelijk informatie verzamelen.

Nu wil ik graag weten tegen welke libcap jullie mod_ruid gelinked hebben, daarom die ldd output.

Keenondots
27/09/06, 12:09
# ldd /etc/httpd/modules/mod_ruid.so
libcap.so.1 => /lib/libcap.so.1 (0x4000d000)
libc.so.6 => /lib/tls/libc.so.6 (0x40012000)
/lib/ld-linux.so.2 (0x80000000)

CentOS 4.4
2.6.8-022stab078.9-smp (Virtuozzo)

RayManZ
27/09/06, 12:10
ldd /usr/lib/apache/mod_ruid.so
libcap.so.1 => /lib64/libcap.so.1 (0x0000002a95662000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95767000)
/lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)

en:

ldd /usr/lib/apache/mod_ruid.so
libcap.so.1 => /lib/libcap.so.1 (0x0032e000)
libc.so.6 => /lib/tls/libc.so.6 (0x00170000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0015a000)

Zou jij me dan kunnen vertellen hoe ik mijn suexec probleem oplos met directadmin :)

Wido
27/09/06, 12:12
Het SUExecUserGroup gebeuren weghalen uit de VirtualHosts van iedereen.

SebastiaanStok
27/09/06, 13:54
Sorry maar ik heb hem nog niet geinstalleerd staan op de productie server :o

@quart: Mappen moeten execute rechten hebben, net zo eender als CGI ;)

quart
27/09/06, 14:33
Ik heb het probleem ondertussen op een andere manier opgelost. Ik heb een 32 bits machientje gepakt en daar werkte het wel op.
@Rollerscapes: De directories stonden op 700 ge-chmod dus die hadden gewoon execute rechten ...

rayden
28/09/06, 16:26
Anyways, is er ook een oplossing voor FreeBSD? mod_ruid werkt niet helemaal lekker icm FreeBSD.. (Want FreeBSD 5.x heef tdie POSIX implementaties niet..)

SebastiaanStok
28/09/06, 16:30
Vreemd, voor zo ver ik weet is BSD ook gebazeerd op posix.
Alleen de kernel is anders, misschien leuke om zelf iets te maken.

Ps: Ik heb die patch van mind gebruikt, als ik een request uitvoert en herstart apache word die request afgebroken maar apache blijft wel gewoon werken.

gjtje
28/09/06, 16:53
ldd mod_ruid.so
linux-gate.so.1 => (0xffffe000)
libcap.so.1 => /lib/libcap.so.1 (0xb7f69000)
libc.so.6 => /lib/libc.so.6 (0xb7e4c000)
/lib/ld-linux.so.2 (0x80000000)


ldd mod_ruid.so
linux-gate.so.1 => (0x0088b000)
libcap.so.1 => /lib/libcap.so.1 (0x0059f000)
libc.so.6 => /lib/libc.so.6 (0x00e77000)
/lib/ld-linux.so.2 (0x0088c000)

SebastiaanStok
01/10/06, 15:55
Ik heb hem vandaag geinstalleerd :)
Man dat noem ik nog is snelheid :D



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: :huh: libc is bijgewerkt, maar zonder mijn mede weten :X (Opzich geen probleem, nu werkt nmap te minsten weer)

luser
10/11/06, 23:41
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).

Wido
10/11/06, 23:55
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.

luser
11/11/06, 00:00
Uit dat zicht is het wel boeiend, dat klopt zeker.

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

gjtje
11/11/06, 00:01
Niet groter dan alles onder user www-data en varianten draaien, wat zo'n beetje heel veel hosters doen, namelijk erg veel kleiner.

Wido
11/11/06, 00:08
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.

luser
11/11/06, 00:11
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.

SebastiaanStok
11/11/06, 11:20
Sorry als ik je niet helemaal begrijp luser :o
Maar bedoel je nou dat mod_ruid slecht is, of juich je het juist toe?

Wido
11/11/06, 15:01
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.

nopzolder
11/11/06, 15:18
Is er ergens ook een fatsoenlijke guide voor de install van mod_ruid op een DA server?

Wido
11/11/06, 15:30
Je moet eerst zorgen dat je Apache 2 draait, daarna doe je (Debian):


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:

# mod_ruid
RMode config
RUidGid apache apache

Nu gaan we de vhosts openen:

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

Comment daar de SUExec regel, en voeg toe:

RMode config
RUidGid |USER| |GROUP

Je kan het ook heel simpel doen:

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 :)

nopzolder
11/11/06, 16:09
Toppie! ik zal ff kijken hoe ik dat naar centos omzet.

Wido
11/11/06, 16:10
Gaat op CentOS precies het zelfde, alleen moet je dan zorgen dat je libcap-dev via een RPM (yum ofzo?) binnen haalt.

luser
11/11/06, 16:13
Sorry als ik je niet helemaal begrijp luser :o
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.

t.bloo
11/11/06, 16:19
en dat door het gebruik ervan niet alles default op veilig gaat.
duh...

nopzolder
18/11/06, 13:30
Wvb mod_ruid op DA, kun je dan oko zonder problemen apache, mysql en php upgraden?

SebastiaanStok
18/11/06, 13:33
Mod_ruid staat daar los van :)
Maar voor DA bedoe jel? Voor zover ik weet wel.

nopzolder
18/11/06, 14:34
Voorzover ik er wat over kon vinden draait mod_ruid alleen op apache2 toch?

Kenneth
18/11/06, 14:36
wij willen nu ook mod_ruid gaan doen (waren we al eerder van plan) maar ik zit met een paar dingen.

op het moment als je als gewone user in ssh inlogt zie je gewoon als je ls -al /home/ doet Permission denied, alleen als je bijv. ls -al /home/<user>/public_html/ doet zie je alle bestanden van een user en kun je ze lezen.

Hoe kun je dit oplossen zodat alles nog mooi werkt? (omdat mail enzo wordt ook in userdir opgeslagen (DirectAdmin))

chroot? of wat hebben jullie hiertegen :)

SebastiaanStok
23/11/06, 12:20
Zeg ik heb de laatste tijd als ik apache opnieuw start hij gaat lopen zeuren dat de socket al in gebruik is :(

Als ik hem daarna opnieuw start doet hij het wel gewoon, meerdere mensen last van?

@Kenneth:
Ik heb zo'n vermoeden dat de chmod/chown rechten niet goed staan of zo.
Kijk is of die home-directory de goede gebruiker heeft.

ErikKosters
23/11/06, 12:35
@Rollerscapes: Probleem heb ik ook gehad, was een oplossing voor in de run file. Zal ff kijken wat het precies is.

Edit: Ben het kwijt, weet wel dat het ergens in de file '/etc/rc.d/init.d/httpd' was.

SebastiaanStok
23/11/06, 12:52
Laat me raden altijd graceful restart doen?

Kenneth
23/11/06, 17:26
Zeg ik heb de laatste tijd als ik apache opnieuw start hij gaat lopen zeuren dat de socket al in gebruik is :(

Als ik hem daarna opnieuw start doet hij het wel gewoon, meerdere mensen last van?

@Kenneth:
Ik heb zo'n vermoeden dat de chmod/chown rechten niet goed staan of zo.
Kijk is of die home-directory de goede gebruiker heeft.

dat klopt, maar op welke chmod kan ik hem als beste zetten en maakt hoe kan ik instellen dat alles files/dirs goede chmod krijgen? zodat er ook geen problemen met mail server e.d. komen :)

SebastiaanStok
24/11/06, 10:45
Het instellen zou ik niet weten, maar de chmod is enkel nodig als de gebruik niet goed staat.

Misschien even google of zoeken op het DirectAdmin forum.

ErikKosters
25/11/06, 12:59
Heb zojuist mod_ruid geinstalleerd volgens de manier van Wido, echter niet elke output geeft de usernaam als USER voor de PID weer. Soms komt ook gewoon apache tevoorschijn als ik een willekeurige site open.

Sander-
25/11/06, 18:15
Heb zojuist mod_ruid geinstalleerd volgens de manier van Wido, echter niet elke output geeft de usernaam als USER voor de PID weer. Soms komt ook gewoon apache tevoorschijn als ik een willekeurige site open.

hier exact hetzelfde... Iemand een idee?

Files staan op 700 en als ze ik ze aan een andere user toeken doet ie het niet meer. PHP Sessies staan ook op username.

mind
25/11/06, 18:18
Heb zojuist mod_ruid geinstalleerd volgens de manier van Wido, echter niet elke output geeft de usernaam als USER voor de PID weer. Soms komt ook gewoon apache tevoorschijn als ik een willekeurige site open.
Heb je mijn patch uit de 3e post in dit draadje er op los gelaten? Zo niet dan wordt de eerste request van een child proces met de rechten van de parent uitgevoerd. In jou geval dus waarschijnlijk apache.

http://www.webhostingtalk.nl/scripting-techniek-beveiliging/103250-mod_suid-2-mod_ruid-ervaringen-en-tips.html#post762740

Sander-
25/11/06, 18:27
Heb je mijn patch uit de 3e post in dit draadje er op los gelaten? Zo niet dan wordt de eerste request van een child proces met de rechten van de parent uitgevoerd. In jou geval dus waarschijnlijk apache.

http://www.webhostingtalk.nl/scripting-techniek-beveiliging/103250-mod_suid-2-mod_ruid-ervaringen-en-tips.html#post762740

Hoe voer ik die patch uit?

SebastiaanStok
26/11/06, 11:33
Ik heb hem gedaan via de handleiding van php-upload-progresmeter.

Download het zip naar een windows computer pak het uit en upload het uitgepakte bestand naar de server.

Ga naar de map waar je mod_ruid hebt uitgepakt en type:
patch -p1 < loctievanwaardepatchzichbevind

Doe bij vragen bevestigen.
En hij zou moet werken.

ErikKosters
26/11/06, 18:15
Aangezien .htm als eerste wordt gepakt heb ik het volgende html script in de mappen /var/www/html/squirrelmail en /var/www/html/webmail gezet om de klanten zo zonder problemen te kunnen laten webmailen :).

Opslaan als index.htm bestand ;)



<html>
<head>
<title>Webmail</title>
</head>
<frameset cols="*">
<frame name="main" src="http://ip-adres/webmail/index.php" scrolling="auto" noresize>
<noframes>
<body>
Your browser does not support frames
</body>
</noframes>
</frameset>
</html>




<html>
<head>
<title>Squirrelmail</title>
</head>
<frameset cols="*">
<frame name="main" src="http://ip-adres/squirrelmail/index.php" scrolling="auto" noresize>
<noframes>
<body>
Your browser does not support frames
</body>
</noframes>
</frameset>
</html>


Wellicht kan het ook anders, maar dit werkt ook prima!

SebastiaanStok
28/11/06, 10:50
Kennelijk zijn de fouten te wijten SEGFAULTS, die vind ik terug in het error_log :mad: , ik heb nu een coredumb locatie ingesteld.
En ga kijken of ik hem zo ver kan krijgen die te maken :(

Edit: Grr, altijd loopt dat kreng vast en uitgerekend nu krijg ik hem niet meer kapot :rolleyes: :X

SebastiaanStok
01/12/06, 13:26
Ik heb een theorie over hoe ik het probleem kan oplossen, aan de segfault kan ik niets veranderen.
Maar het probleem dat de socket nog in gebruik is kan je mogelijk oplossen door met sleep in je start script hem net iets meer tijd te geven.

Hij kan niet gewoon even de childs stoppen, hij moet wachten tot de rechten zijn terug gezet en dan kan pas kan hij het child als gestopt verklaren.
Gisteren dacht een patch hebben gevonden bleek het voor worker te zijn en niet voor prefork, en de patch was al toegepast op worker zelf :(

Ik moet alleen weer 24 f****** uur wachten voor ik het kan testen.... Anders loopt apache niet vast en kan ik het niet testen!
ALS DIT NIET WERKT WORD IK GEK :mad:

SebastiaanStok
03/12/06, 11:30
Man wat ben ik toch weer goed! :W: :cool:
Ik heb gisteren het sleep toegepast vandaag getest en inderdaad het werkt :)

Door bij het restart gedeelte na stop een sleep 3 te plaatsen heeft script meer tijd om het proces te stoppen, mogelijk moet het hoger worden ingesteld bij meer verbinding, maar dat weet ik nog niet zeker.

Het volgende wat ik wil testen is of hij aangeeft dat hij is gestopt en pid nog bestaat.
Maar voor nu heb ik het weer werkend gekregen.

Sander-
03/12/06, 12:50
Ik heb mod_ruid via de .deb van wido geinstalleerd. Helaas kan ik hem daardoor dus niet updaten.

Wido, heb jij zelf inmiddels al een patched versie?

SebastiaanStok
03/12/06, 17:25
Het goede nieuws is dat ik er achter ben wat het is :D
Alleen ben ik nog aan het lezen en heb dus nog voor zover geen oplossing :(
http://bugs.php.net/bug.php?id=27810

Kennelijk is de bug nog steeds aanwezig :(
Maar waarom doet php er dan niets aan het te fixen?

Herbert
04/12/06, 13:28
Ik heb de mod_ruid-0.6-3.i386.rpm voor CentOS geinstaleerd.
In de ruid.conf staat nu:
LoadModule ruid_module modules/mod_ruid.so
User apache
Group apache
#
#
#
RMode stat
#RGroups apachetmp
#
#RMode config

#Example follows:
#NameVirtualHost 192.168.0.1
#<VirtualHost example.com>
# ServerAdmin webmaster@example.com
# DocumentRoot /home/example.com/public_html
# ServerName example.com
# ServerAlias www.example.com
# RMode config
# RUidGid user1 group1
# RGroups apachetmp
#</VirtualHost>

Mijn control panel is ISPConfig, ik ga er even vanuit dat bij het onderste voorbeeld de user is: web7_info_hmnet en de group: web7
Ik neem aan dat je nu in de VirtualHost het volgende moet zetten:
RMode config
RUidGid web7_info_hmnet web7
RGroups apachetmp

Zo als ik begrijp komt mijn VirtualHost er dan zo uit te zien?
ServerName www.hmnet.nl:80
ServerAdmin webmaster@hmnet.nl
DocumentRoot /var/www/web7/web
ServerAlias hmnet.nl
DirectoryIndex index.html index.htm index.php index.php5 index.php4 index.php3 index.shtml index.cgi index.pl index.jsp Default.htm default.htm
ScriptAlias /cgi-bin/ /var/www/web7/cgi-bin/
AddHandler cgi-script .cgi
AddHandler cgi-script .pl
ErrorLog /var/www/web7/log/error.log
AddType application/x-httpd-php .php .php3 .php4 .php5
php_admin_flag safe_mode On
php_admin_value open_basedir /var/www/web7/
php_admin_value file_uploads 1
php_admin_value upload_tmp_dir /var/www/web7/phptmp/
php_admin_value session.save_path /var/www/web7/phptmp/
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
Alias /error/ "/var/www/web7/web/error/"
ErrorDocument 400 /error/invalidSyntax.html
ErrorDocument 401 /error/authorizationRequired.html
ErrorDocument 403 /error/forbidden.html
ErrorDocument 404 /error/fileNotFound.html
ErrorDocument 405 /error/methodNotAllowed.html
ErrorDocument 500 /error/internalServerError.html
ErrorDocument 503 /error/overloaded.html
AliasMatch ^/~([^/]+)(/(.*))? /var/www/web7/user/$1/web/$3
AliasMatch ^/users/([^/]+)(/(.*))? /var/www/web7/user/$1/web/$3
RMode config
RUidGid web7_info_hmnet web7
RGroups apachetmp

Welke aanpassing moet ik nog meer doen?

SebastiaanStok
04/12/06, 14:16
Klopt helemaal :)

Ik ben er by the way achter gekomen dat clamav voor php problemen geeft, dat is wat ik kon ophalen uit de backtrace

Of hier mee ook het probleem van het starten is opgelost ga ik nu even testen :)
reload werkt in iedere geval weer.

Edit: Ik geloof het wel :eek: :D Nu even een paar dagen laten draaien en dan verder kijken.

Herbert
04/12/06, 15:36
Ik moet alles weer even doorlezen hier, de webmail (SquirrelMail) doet het niet onder mod_ruid.
De webmail draaid onder een eigen virtualhost hier, als ik me niet vergis staat er ergens wat over hier..

SebastiaanStok
04/12/06, 21:06
Naar mijn mening kan je de webmail gewoon beter doen via een appart subdomein, kan je hem ook gelijk goed beveiligen met SSL :)

Herbert
04/12/06, 21:16
Hier loopt die als webmail.adslnetwerk.com
Het probleem is dat hij de user.prefs niet kan openen, die staan op user apache.
Maar ik zie net dat alle maildirs ook niet op gebruikersnaam staan, volgens mij is er veel werk te doen voordat het lekker loopt hier.

Sander-
04/12/06, 21:46
Als de maildirs niet op gebruikersnaam staan, dan gaat het toch juist heel makkelijk? dan zorg je dat de gebruiker die je in de vhost instelt dezelfde is als die eigenaar is van de Maildirs en die geef je ook de rechten op de map met de files van de webmail.

Herbert
04/12/06, 23:03
Sorry ik had het verkeerd, Maildir staat op root maar Mail staat op de user.
Dit is dus goed..
Met webmail ben ik nog bezig, hij moet nu nog de .prefs wegschrijven onder de user en niet apache of webmail als user.

fastrep
15/12/06, 14:24
Nog eens terugkomen hierop.
Ik heb nu zo'n server met mod_ruid2 in gebruik genomen. Alles werkt goed, behalve het volgende:

Dec 15 11:24:49 neon postfix/sendmail[17566]: fatal: no login name found for user ID 1084

Dit gebeurt wanneer iemand de mail() functie gebruikt in PHP, die steunt op de binary /usr/sbin/sendmail. Dit gebeurt dus nu met de virtuele userID.
Maar die sendmail functie van postfix gaat dus in de /etc/passwd checken met welke user de sendmail wordt opgeroepen. En als hij die niet vindt, wordt de mail dus gewoon weggesmeten...

Hier de uitleg van de maker van postfix: http://groups.google.be/group/mailing.postfix.users/browse_frm/thread/bac9641e2b1a15c9/650f91d7111ca2e3?lnk=st&q=fatal%3A+no+login+name+found+for+user+ID&rnum=1&hl=nl#650f91d7111ca2e3

Maar ja, daar kom ik ook niet verder mee. Ik kan toch moeilijk aan PHP gaan zeggen dat hij sendmail met een parameter gaat oproepen? Of is er een of andere manier waarop dat wel kan?
Of zou ik een sendmail-vervanging kunnen maken? Ik heb al geprobeerd een scriptje te maken /usr/sbin/sendmail:
#!/bin/sh
/usr/sbin/sendmail -f httpd@serverhostname.be $1
Maar dat is iets te simplistisch denk ik, want het werkt niet.

Ik heb dan maar alle virtualhosts in de passwd-file gestoken. Maar als iemand dit probleem op een elegante manier kan oplossen, zou ik dat wel leuk vinden :)

Peter

Wido
15/12/06, 14:26
Je moet er voor zorgen dat al die userID's natuurlijk wel op jouw systeem bestaan :)

SebastiaanStok
15/12/06, 14:28
Je kan php.ini instellen wat jouw sendmail path is en wat je daar voor parameters aan wild meegeven.

fastrep
15/12/06, 14:34
Je moet er voor zorgen dat al die userID's natuurlijk wel op jouw systeem bestaan :)

?? Is het niet de bedoeling van een virtualhost dat de users niet in de password file staan?

Nu, technisch kan het wel. We hebben nu eindelijk ons controlpanel gemaakt, dat alle config files en directory's automatisch aanmaakt. Dus die moet dan ook maar die ene regel in de /etc/passwd zetten.

Maar toch, in theorie was dit toch niet nodig?

gjtje
15/12/06, 14:49
De bedoeling van een virtual host is dat er meer dan het aantal fysieke hosts op een host aanwezig zijn. Het wel of niet hebben van een user in /etc/passwd heeft daar vrij weinig mee te maken.

vaplu
16/12/06, 17:24
Je moet er voor zorgen dat al die userID's natuurlijk wel op jouw systeem bestaan :)
Ik weet niet hoeveel virtualhosts jullie draaien, maar aangezien jullie met loadbalancing werken, zouden jullie enorm veel entries moeten hebben in jullie /etc/passwd file op elke (load balanced) webserver ..... klopt dat?

en als dat klopt .. hoe houden jullie al die die /etc/passwd files synchroon? rsync of hebben jullie mooie truc waar door er maar één passwd file op jullie storage platform staat?

(of krijg ik met het beantwoorden van deze vragen iets te veel kijk in de keuken? ... hoe dan ook, ben benieuwd naar de reactie en hoop er wat van te leren)

Wido
16/12/06, 18:51
Ik weet niet hoeveel virtualhosts jullie draaien, maar aangezien jullie met loadbalancing werken, zouden jullie enorm veel entries moeten hebben in jullie /etc/passwd file op elke (load balanced) webserver ..... klopt dat?

Klopt, daar staan een paar duizend entry's in.


en als dat klopt .. hoe houden jullie al die die /etc/passwd files synchroon? rsync of hebben jullie mooie truc waar door er maar één passwd file op jullie storage platform staat?Elke server draait een daemon die we zelf gemaakt hebben. Via die daemon sturen we elke server zijn nieuwe httpd.conf (eigenlijk een virtual.conf die we in de httpd.conf includen) en een nieuwe passwd file.

Daarna sturen we het commando voor een apachectl graceful.

LB06
06/05/07, 12:31
Ben sindskort ook aan de slag gegaan met mod_ruid. Op zich werkt het goed, maar er zijn nog enkele serieuze showstoppers. Misschien iemand hier ervaring mee heeft?

- Wij gebruiken ook aliases en userdirs, aangezien in onze "klantenkring" lang niet iedereen een domein heeft. Echter, met mod_ruid is het alleen mogelijk binnen een virtualhost context te user en group te bepalen. Zijn hier oplossingen voor?

- We willen ook PHP5 naast PHP4 gaan draaien. Aangezien 2 apachemodules naast elkaar blijkbaar niet gaat werken, zijn we gedwongen om PHP5 via cgi te draaien. edit, foutje: bij php5-cgi draait hij onder de defaultuidgid, terwijl het bestandje precies dezelfde eigenaar heeft als de php4 versie.

SebastiaanStok
06/05/07, 12:44
Niet via stat werken maar enkel via config.
Met de rest kan ik je niet verder helpen.

LB06
06/05/07, 12:45
Niet via stat werken maar enkel via config.
Met de rest kan ik je niet verder helpen.
Dan doet hij het idd wel voor CGI. Hoewel het wel vreemd is, is niet zo erg dat stat niet werkt. Die gingen we toch al niet gebruiken.

Maar ook RMode config werkt niet in een andere context dan de globale context of binnen een vhost. Heeft iemand hier een oplossing voor? Bvd! :)

vaplu
24/06/07, 22:18
Op een server ben ik trouwens over gestapt op mpm-itk, welke hetzelfde lijkt te doen, alleen dan zonder extra module. ;)

Met welke distro werk je? In Debian Etch (stable) staat over mpm-itk nog het volgende:

"Please note that this MPM is highly experimental, and is not from the same tree as the other MPMs."

Hoop dat je het niet in productie draait ;)


Ik ga binnenkort weer eens experimenteren met de mod_suid voor de Apache 1.3.x gebruikers onder ons en een HOWTO publiceren, ben nu al in gesprek met de developer over bepaalde opties enz.

Heb je al wat online staan of is het er niet meer van gekomen?

Pur
26/06/07, 15:11
Ik merkte vandaag een probleempje op met mod_ruid in combinatie met Nagios/CGI's.

Als ik in m'n vhost het volgende gebruik:

RMode config
RUidGid nagios nagios

Dan krijg ik foutmelding ala deze:

[Tue Jun 26 12:39:41 2007] [error] [client 192.168.1.64] (13)Permission denied: unable to connect to cgi daemon after multiple tries
: /usr/local/nagios/sbin/status.cgi, referer: http://192.168.1.203/side.html

Als ik Rmode verander naar stat (niet wenselijk maar ala) met de file permissies op nagios:nagios zelfde foutmelding.

Pas als ik de file rechten verander naar nobody:nogroup in combinatie met stat komt die foutmelding niet meer voor.

Dit overigens met Apache 2.2.

Wat doe ik fout?




Hoort dit topic eigenlijk niet thuis onder Server, Services en Beveiliging?

SebastiaanStok
26/06/07, 15:18
Kan je die dan beter niet onder mod_ruid draaien?

vaplu
26/06/07, 17:54
Kan je die dan beter niet onder mod_ruid draaien?

Is het sowieso niet beter (gevoelsmatig) dat je .cgi via suexec laat lopen?

gjtje
26/06/07, 18:13
Zolang het moederproces maar onder een bepaalde user draait dan wordt alles wat daaruit voort komt (bijv cgi) ook onder die user uitgevoerd (voor zover ik weet).

Pur
26/06/07, 18:25
Is het sowieso niet beter (gevoelsmatig) dat je .cgi via suexec laat lopen?

Misschien, maar dat oogt ook weer wat dubbelop omdat mod_ruid hetzelfde maar dan breder zou moeten doen dan suexec. Anders zit je in elke virtual config een mod_ruid & suexec config op te nemen.

Either way doet dit probleempje zich alleen voor in de combi mod_ruid en cgi's dus ben benieuwd of anderen dit ook hebben opgemerkt. Het oogt dan alsof de cgid die gespawned wordt niet de juiste uid/gid mee krijgt.

vaplu
26/06/07, 18:34
dus ben benieuwd of anderen dit ook hebben opgemerkt.
Uuuh .... Wido!!?

1ms
02/07/07, 21:57
frontpage hier gewoon uit staan. Die rommel wil niemand :p

Ik heb tevens een nieuw probleem:

ipadres/~username werkt nu niet meer...

Nu heb ik dat wel weer werkend gekregen. Alleen de sessies die in /tmp staan krijg ik een permission denied op. iemand een oplossing hiervoor?


chmod 777 /tmp :)

mind
03/07/07, 01:43
Either way doet dit probleempje zich alleen voor in de combi mod_ruid en cgi's dus ben benieuwd of anderen dit ook hebben opgemerkt. Het oogt dan alsof de cgid die gespawned wordt niet de juiste uid/gid mee krijgt.Heb je je mod_ruid gepatched? Zie http://www.webhostingtalk.nl/scripting-en-programmeren/103250-mod_suid-2-mod_ruid-ervaringen-en-tips.html#post762740
anders zou dat een verklaring kunnen zijn.

vaplu
03/07/07, 20:41
chmod 777 /tmp :)

/tmp is standaard 777 .... je bedoelt waarschijnlijk:

chmod 777 /tmp -R

Keenondots
04/07/07, 09:13
Laten we daar 1777 van maken :)

vaplu
08/07/07, 13:23
Laten we daar 1777 van maken :)

ofcourse :)

Pur
14/07/07, 12:17
Heb je je mod_ruid gepatched? Zie http://www.webhostingtalk.nl/scripting-en-programmeren/103250-mod_suid-2-mod_ruid-ervaringen-en-tips.html#post762740
anders zou dat een verklaring kunnen zijn.

Yep maar dat veranderde niks aan de fout situatie bij mij helaas.

mind
15/07/07, 22:17
Wacht ff je gebruikt mod_cgid... mod_cgid en mod_ruid gaan niet samen omdat de deamon na de start niet meer van uid kan wisselen. Probeer mod_cgi eens te gebruiken ipv. mod_cgid. Dit gaat wel ten kosten van wat extra overhead, maar dat is een keuze die je zelf moet maken...

Costeijn
04/08/07, 01:24
Klein vraagje. Ik gebruik ook mod_ruid en nu probeer ik via een webinterface een virtualhost aan te maken in me httpd.conf. Godzijdank kan dit niet. Maar hoe kan ik zorgen dat ik/mijn gebruiker toegang heeft tot /etc/apache2/httpd.conf? Ik doe het via fwrite.

SebastiaanStok
04/08/07, 11:25
Het bestand httpd.conf staat meestal onder root, en zelfs dan moet je de webserver opnieuw starten (kan enkel als root)

Wat ik zelf doe is een cronjob draaien onder root die kijkt of het bestand /tmp/update_virhosts bestaat en zo ja dan haalt hij de gegevens op uit de database. Overschrijft het virhosts bestand en doet de webserver opnieuw starten.

Je kan in httpd.conf bestanden includen met Include.



Include virhosts.conf


In Apache2.2 word dit gebruikt voor het verdelen van de configuratie, wat echt een stuk prettiger werkt :o

Edit: Oh vergeten, het bestand /tmp/update_virhosts doe ik gewoon aanmaken als een andere gebruiker dan root. gewoon in php met touch() Op deze manier heb ik maar een proces welke het update gedeelte doet en niet dat meerdere processen naar een bestand gaan schrijven met alle gevolgen van dien...

Costeijn
04/08/07, 11:30
Kijk hier kan ik wat mee. Ik zal er eens mee spelen. Bedankt!

Als ik een bestand aanmaken met touch() komt hij in mijn /home/$user/public_html. Hoe kan ik deze laten wegschrijven in /tmp? Ik heb /tmp niet als een partitie maar als een onderdeel van /.

-- edit

touch(/tmp/blaat.txt);

HielkeJ
29/09/07, 01:14
Ik probeer op dit moment de patch van mind door te voeren. Helaas geeft hij hierbij een error. Weet iemand misschien wat ik fout doe?


lamp01:/usr/src# tar zxf mod_ruid-0.6b.tar.gz
lamp01:/usr/src# cd mod_ruid-0.6b
lamp01:/usr/src/mod_ruid-0.6b# patch -p1 < ../mod_ruid-0.6-nodefuidgid.patch
missing header for unified diff at line 3 of patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- mod_ruid.c.nodefuidgid 2005-08-31 03:22:35.000000000 +0200
|+++ mod_ruid.c 2006-09-08 22:24:28.000000000 +0200
--------------------------
File to patch: ../mod_ruid-0.6-nodefuidgid.patch
patching file ../mod_ruid-0.6-nodefuidgid.patch
Hunk #1 FAILED at 29.
Hunk #2 FAILED at 62.
Hunk #3 FAILED at 195.
Hunk #4 FAILED at 347.
4 out of 4 hunks FAILED -- saving rejects to file ../mod_ruid-0.6-nodefuidgid.patch.rej
lamp01:/usr/src/mod_ruid-0.6b#
Dit is op een Debian VPS onder Ubuntu ( XEN ).

fastrep
24/11/07, 14:54
Werkt mod_ruid2 enkel bij NameVirtualHosts?
Ik heb nu een paar SSL-virtualhosts op een server staan, en daar lijkt dit niet te werken. Zou dit kunnen???

Peter

SebastiaanStok
24/11/07, 14:58
Kan je misschien de configuratie die je gebruikt posten?
Ik heb er geen enkel probleem mee bij zowel gewoon als SSL!

fastrep
24/11/07, 17:10
Bij deze (staat verspreid over meerdere bestanden)

LoadModule ruid_module modules/mod_ruid.so

NameVirtualHost 195.225.166.23
#NameVirtualHost 195.225.166.26

<VirtualHost 195.225.166.26:443>
DocumentRoot /data/vhome/vhost0140/http
CustomLog /data/vhome/vhost0140/log/https_access_log combined
ErrorLog /data/vhome/vhost0140/log/https_error_log

AccessFileName .htaccess

Rmode config
RuidGid #1144 #1144

SSLEngine on
...
</VirtualHost>
<VirtualHost 195.225.166.26:80>
# zelfde, maar zonder de ssl
</VirtualHost>

<VirtualHost 195.225.166.23>
ServerName kidsavenue.level27.be
UseCanonicalName off
DocumentRoot /data/vhome/vhost0144/http
CustomLog /data/vhome/vhost0144/log/access_log combined
ErrorLog /data/vhome/vhost0144/log/error_log

AccessFileName .htaccess

Rmode config
RuidGid #1148 #1148
<IfModule mod_ssl.c>
SSLEngine off
</IfModule>
...
</VirtualHost>

Het rare is dat het gedeeltelijk wel werkt. Want de files onder /data/vhome/vhostXXXX zijn mod 770 en uid/gid 1144/1144, dus niet leesbaar voor httpd, de user waaronder apache normaal draait.
't Is precies enkel perl (via CGI) die blijkbaar niet werkt:
http://detulp.level27.be/awstats/awstats.pl?config=vhost0140&lang=nl
De files waarover hij klaagt zijn uid/gid ook hetzelfde als de documentroot. Vreemd toch vind ik. Ik zoek ondertussen verder. Als iemand iets weet misschien?

SebastiaanStok
24/11/07, 17:17
Dus probleem zit bij CGI?
Daar had iemand anders ook problemen mee, daar kan je beter suexec gebruiken.

SebastiaanStok
08/01/08, 15:34
Misschien een beetje laat :)
Maar HielkeJ, als hij vraagt welk bestand hij moet patchen moet je mod_ruid.c opgeven en niet de patch zelf ;)

Vandaag de test server opnieuw geïnstalleerd en had dat zelfde probleem.

nieuwhier
25/03/08, 23:36
Is er iemand die de frontpage server extensions, in combinatie met directadmin en mod_ruid werkend heeft?

Is er iemand die al een antwoord op deze vraag heeft gevonden ? Frontpage extensions werkend onder mod_ruid ?

SebastiaanStok
26/03/08, 11:04
Volgens mij niet, Frontpage-extensions is gewoon iets wat je niet WIL gebruiken!
Er zitten tal van bugs in en de versie die voor Apache is gemaakt is zwaar verouderd.

Als deze extensie via een eigen techniek de bestanden opvraagt kan je lang zoeken.
Want dan betekend het gewoon dat hij niet via het systeem van Apache werkt en dus andere modules gewoon negeerde.

nieuwhier
26/03/08, 12:00
Volgens mij niet, Frontpage-extensions is gewoon iets wat je niet WIL gebruiken!
Er zitten tal van bugs in en de versie die voor Apache is gemaakt is zwaar verouderd.
Het is niet iets dat IK wil gebruiken maar ja, klanten he.... Leven met ze is moeilijk maar zonder helemaal...

t.bloo
26/03/08, 12:25
je kunt natuurlijk gewoon voor deze klanten een windows server aanschaffen

nieuwhier
26/03/08, 12:30
Toevallig, en dat staat hier los van, zijn er al machines besteld om windows hosting aan te gaan bieden. Maar voor dit probleem is het wel een beetje een rigoreus....

bigall
28/03/08, 19:15
Ik heb er destijds voor gekozen om frontpage niet meer te ondersteunen.
Maar niet alleen omdat het niet goed met mod_ruid werkt, maar omdat het pakket vanaf mei 2006 niet meer door Microsoft werd ondersteund, en ik nogal wat twijfels had bij de veiligheid van het pakket.

<offtopic>
Nog een tip voor de mensen die ook van de frontpage extensie af willen;
Ik kreeg het geheel niet weg uit DirectAdmin, nadat ik de module had verwijderd uit de apache configuratie.
Om frontpage uit de DirectAdmin interface te krijgen kun je gebruiken maken van de info op http://directadmin.com/features.php?id=754
</offtopic>

sander3
30/04/08, 23:38
Ik heb zojuist het één en ander veranderd in mijn structuur. Het stond eerst wat door elkaar, nu heb ik alle virtual hosts in de home directory gezet.

Alleen krijg ik nu geen toegang meer tot mijn virtual hosts. Ik krijg een 403 error in de browser, en de volgende error staat in de error_log


[Wed Apr 30 20:45:46 2008] [error] [client <mijn-ip>] (13)Permission denied: file permissions deny server access: /home/<virtual-host>/index.html
[Wed Apr 30 21:59:21 2008] [error] [client <mijn-ip>] (13)Permission denied: access to /index.php denied
[Wed Apr 30 21:59:21 2008] [error] [client <mijn-ip>] (13)Permission denied: access to /index.html denied


Het gedeelte mbt ruid van de httpd.conf is alsvolgt:



LoadModule ruid_module modules/mod_ruid.so

User www
Group www


De virtualhost configuratie is:



<VirtualHost *:80>
RMode config
RUidGid sanderh www
DocumentRoot "/home/sander-h/public_html"
ServerName sander-h.nl
ServerAlias www.sander-h.nl
</VirtualHost>

Bij RUidGid heb ik de volgende combinaties geprobeerd:
root root, root www, www www, sanderh sanderh, sanderh root, root sanderh en www sanderh maar niets werkt.

De directory rechten van een virtual-host directory zijn 700, en de eigenaar heb ik staan op sanderh, de groep op www.

Ik word er niet goed van, maar het zal wel iets kleins zijn.. ->| En ik hoop dat iemand me kan helpen.

Ik kreeg dit topic van iemand, dus vandaar dat ik er nog maar een bericht in plaats, aangezien er hier al zo'n lange discussie over ging.. :)

SebastiaanStok
01/05/08, 11:16
root zal zo wie zo niet werken ;)
De bestanden moeten op sander.www staan en ook mod_ruid ingesteld staan.

Mappen moeten op chmod 700 staan en bestanden op 600.
Wel apache herstarten he :D

GlennMatthys
22/10/08, 17:40
Is er het besef dat als je de vhost onder zijn eigen user laat uitvoeren, dat die dan ook onmiddelijk write access heeft tot alle bestanden onder die DocumentRoot?

nieuwhier
22/10/08, 17:45
In de documentroot van de betreffende vhost bedoel je dan ? Is toch ook de bedoelding denk ik ? Anders zou apache user die rechten hebben.

SebastiaanStok
23/10/08, 11:33
Is er het besef dat als je de vhost onder zijn eigen user laat uitvoeren, dat die dan ook onmiddelijk write access heeft tot alle bestanden onder die DocumentRoot?

Kan je iets duidelijker hier in zijn :bored:
Dat is toch juist de bedoeling, je wilt iedereen een eigen webruimte geven die ook onder zijn of haar account word uitgevoerd ;)
En daar onder vallen ook schrijfrechten.

Edit:
Kennelijk ging er iets niet helemaal goed...
"Dit forum vereist dat je 60 seconden wacht tussen het verzenden van berichten. Probeer het nogmaals over 46 seconden."

Maar ik had al gepost :huh:

mind
02/11/08, 23:05
De ontwikkeling van mod_ruid staat al een behoorlijke tijd stil. Bugs worden niet gefixt en functionaliteit wordt niet verder uitgebreid. Op zich voldoet de module prima (mits gepatched) maar er kunnen nog veel meer leuke dingen met posix capabilities.
Afgelopen week ben ik wat aan het stoeien geweest met de module en heb de mogelijkheid toegevoegd om per virtual host een chroot omgeving in te stellen (eventueel per host verschillend). Uiteraard wordt deze na de request weer ongedaan gemaakt, zo dat een child meerder requests kan uitvoeren.

Gebruik is simpel. E.e.a. werkt exact als mod_ruid (Config is 1 op 1 uitwisselbaar). Er is alleen een optie toegevoegd:

RChrootRootDir CHROOT DOCUMENT_ROOT

Stel de documentroot was /home/virtual/domain.tld/public_html en /home/virtual moet de nieuwe root worden, dan is het toevoegen van een:

RChrootRootDir /home/virtual /domain.tld/pulblic_html

alles wat nodig is (document root optie kan vervallen bij een virtualhost).

Om verwarring met mod_ruid te voorkomen heb ik de naam van de module aangepast in mod_chruid. In de bijlage zitten twee bestanden. De source van de module en de selinux module die nodig is om httpd toe te staan een chroot functie uit te voeren.

LET op deze module is experimenteel en gebruik is geheel op eigen risico. Zelf pas ik hem op dit moment met succes toe op een centos 5.x. machine, maar dat garandeert niets voor andere configuraties.

Mocht je deze module gaan testen/gebruiken dat wordt terugkoppeling uiteraard ZEER op prijs gesteld.

Veel plezier er mee...

SebastiaanStok
26/06/09, 16:46
@Mind: ik zal wel last heb van de warmte maar ik zie die bijlagen niet meer :huh:

davhog
26/06/09, 18:08
In de documentroot van de betreffende vhost bedoel je dan ? Is toch ook de bedoelding denk ik ? Anders zou apache user die rechten hebben.

Als het goed is heeft de apache user enkel lees rechten voor de web directory van de user. Met mod_ruid veranderd de apache user opeens naar de user van de klant en heeft dus opeens SCHRIJF rechten tot alle bestanden. Dit is lastig te voorkomen zonder de klant de rechten te ontnemen eigen bestanden te wijzigen. Dit is een redelijk beveiligingsrisico omdat een lek PHP script nu gegarandeerd de gehele website onderuit kan halen.

mind
23/07/09, 21:00
Op speciaal verzoen van Rollerscapes versie 0.2 van mod_chruid.

Keenondots
24/07/09, 12:25
De ontwikkeling van mod_ruid staat al een behoorlijke tijd stil. Bugs worden niet gefixt en functionaliteit wordt niet verder uitgebreid. Op zich voldoet de module prima (mits gepatched) maar er kunnen nog veel meer leuke dingen met posix capabilities.
Afgelopen week ben ik wat aan het stoeien geweest met de module en heb de mogelijkheid toegevoegd om per virtual host een chroot omgeving in te stellen (eventueel per host verschillend). Uiteraard wordt deze na de request weer ongedaan gemaakt, zo dat een child meerder requests kan uitvoeren.

Gebruik is simpel. E.e.a. werkt exact als mod_ruid (Config is 1 op 1 uitwisselbaar). Er is alleen een optie toegevoegd:

RChrootRootDir CHROOT DOCUMENT_ROOT

Stel de documentroot was /home/virtual/domain.tld/public_html en /home/virtual moet de nieuwe root worden, dan is het toevoegen van een:

RChrootRootDir /home/virtual /domain.tld/pulblic_html

alles wat nodig is (document root optie kan vervallen bij een virtualhost).

Om verwarring met mod_ruid te voorkomen heb ik de naam van de module aangepast in mod_chruid. In de bijlage zitten twee bestanden. De source van de module en de selinux module die nodig is om httpd toe te staan een chroot functie uit te voeren.

LET op deze module is experimenteel en gebruik is geheel op eigen risico. Zelf pas ik hem op dit moment met succes toe op een centos 5.x. machine, maar dat garandeert niets voor andere configuraties.

Mocht je deze module gaan testen/gebruiken dat wordt terugkoppeling uiteraard ZEER op prijs gesteld.

Veel plezier er mee...
Ben vooral benieuwd hoe je omgaat met std. PEAR includes e.d.

SebastiaanStok
27/07/09, 18:18
Persoon ben ik van mening dat je PEAR includes gewoon door de website zelf moet laten regelen. Als je een versie bijwerkt sloop je in het ergste geval gelijk tal van websites die niet compatible zijn.

Toon
25/11/10, 12:41
Ik ben ook aan het testen met RDocumentChRoot, ik vraag me alleen af hoe je nu het beste PHP als CGI kunt laten draaien?

In de /usr/local/php kun je niet meer komen..

dreamhost_nl
25/11/10, 13:39
Zou je hiervoor niet even een nieuwe topic aanmaken? De originele topic komt uit 2006 en hetgeen er in wordt verteld is inmiddels al verschrikkelijk (gelukkig maar) achterhaald.

Toon
25/11/10, 14:20
Zou je hiervoor niet even een nieuwe topic aanmaken? De originele topic komt uit 2006 en hetgeen er in wordt verteld is inmiddels al verschrikkelijk (gelukkig maar) achterhaald.


Zie niet in waarom, het slaat exact op de inhoud van dit topic.