mod_suid(2)/mod_ruid ervaringen en tips

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

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.

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....

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?

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.

Dat bedoel ik inderdaad... Hoe heb jij dit nu opgelost? phpmyadmin werkt zonder problemen. Helaas webmail niet...

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.

inderdaad een goed idee... Gewoon een redirect maken ik ga hier even mee aan de slag en kijken of het ook werkt. Tnx

Oorspronkelijk geplaatst door RayManZ

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

Oorspronkelijk geplaatst door Wido

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.

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!

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

Oorspronkelijk geplaatst door Wido

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.

@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 apacheoot. 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?

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.