Onderwerp: install & config Mod_ruid

Ik heb altijd su_php gebruikt maar aangezien dat toch bepaalde problemen met zich meebrengt ( geen accelerators bijv ).

Zit ik te kijken naar mod_ruid ik heb deze uit het volgende topic
( http://www.webhostingtalk.nl/scripti...kkelingen.html (mod_ruid nieuwe ontwikkelingen) )

Kan iemand mij vertellen hoe ik deze op een Directadmin server krijg? Want ik kan verder niets vinden over hoe ik hem installeer of instel.

Je maakt 35 euro over met Paypal naar randy@aklmedia.nl en hij doet de rest

Ik ga even van EL5 uit. Op Debian is het eerste regeltje anders. (yum == apt-get en de module heet gewoon libcap)
Onderstaand is copy, paste & pray...

Code:

yum install libcap-devel
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
cd /usr/local/directadmin/data/templates
cp virtual_host2* custom/
cd custom
wget http://crew.pcextreme.nl/files/linux...od_ruid.tar.gz
tar -xzf da_vhosts_templates_apache2_mod_ruid.tar.gz
rm -f da_vhosts_templates_apache2_mod_ruid.tar.gz
nano /etc/httpd/conf/httpd.conf
  
Voeg toe boven "ServerAdmin admin@localhost": (Verander dit meteen even naar je eigen adres)
# mod_ruid
RMode config
RUidGid apache apache

echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

Dat ga ik eens uittesten.
Ik probeer het eerst liever zelf zodat ik weet wat er gebeurd. Mocht het niet lukken komt die 35 euro alsnog jou kant op randy

Ik neem aan dat het met die versie van Mind op dezelfde manier werkt het installeren.

Aangezien ik mijn eigen post niet meer aan kan passen, hoe kan ik zien of mod_ruid ook daadwerkelijk werkt?

Door de zoekfunctie te gebruiken: http://www.webhostingtalk.nl/technis...che-staan.html

Inderdaad, dat had ik dus moeten doen
Het werkt in ieder geval Bedankt Randy

Oorspronkelijk geplaatst door Jimmy1987

Inderdaad, dat had ik dus moeten doen
Het werkt in ieder geval Bedankt Randy

Nu nog wel de rechten homedirs even goed zetten opdat er geen apache-bestanden meer zijn. Dat kan met de hand, dat kan nog makkelijker met een script dat bij DA zit:

Code:

cd /usr/local/directadmin/scripts && ./set_permissions.sh user_homes

Oh daar was dus een script voor
En ik alles maar met de hand doen

Ach ja weer wat geleerd

Wat ik trouwens wel gemerkt heb. Toen ik op een map de volgende regels uitvoerde:

find /home/<user>/ -type d -print0 | xargs -0 chmod 700
find /home/<user>/ -type f -print0 | xargs -0 chmod 600

Werkt het vervolgens perfect Geen gezeik met rechtenkwesties ed. Maar wanneer ik doe:

find /home/ -type d -print0 | xargs -0 chmod 700
find /home/ -type f -print0 | xargs -0 chmod 600

Dan krijg ik bij alle domeinen op de server een forbidden melding.

Is dit op een manier op te lossen? Want elke user apart gaan doen zie ik nu ook weer niet zo zitten

Zo ingewikkeld hoeft het niet te zijn...

find /home/*/ en de rest van je regel

en 0664 en 0755 lijkt me handiger.

Oorspronkelijk geplaatst door Spyder01

Zo ingewikkeld hoeft het niet te zijn...

find /home/*/ en de rest van je regel

en 0664 en 0755 lijkt me handiger.

waarom wil je bestanden zowel op gebruiker als op groep lees en schrijfrechten geven? Die gebruiker is tevens z'n eigen groep dus dat lijkt me een beetje onzinnig. Maar ik kan het mis hebben, zit hier een reden achter?

Randy, in hoeverre baken jij af dat de functionaliteiten van mod_ruid niet misbruikt worden om root te worden? Denk aan het risico van Apache exploits (momenteel geen issue natuurlijk, maar wat als er een 0-day exploit toegepast wordt, gefocussed op mod_ruid users?), of misbruik van de POSIX functies van PHP.

De mod_ruid module is interessant, maar als ik zo de reacties op WHT lees van verschillende leden heb ik de indruk dat velen niet realiseren dat het ook weer nieuwe security issues introduceert die goed afgeschermd moeten worden (wat overigens ook in de README staat).

Wouter,

Ik heb er geen problemen mee. het 'master' Apache proces draait ook als root. Met de 777-ellende, allow_url_fopen én een oude Joomla installatie die te vinden is op iedere drukke shared server heb je meer problemen.

Voordeel van mod_ruid is ook dat je 'bagger' in de /tmp meteen kunt traceren doordat deze van de user zijn en niet van apache. Al zet ik sessies standaard in memcached.

Geen problemen gehad met exploits of what so ever. Wel weet ik dat een enkeling problemen heeft met de oude, ongepatche versie van mod_ruid (niet die van Kees hier (mod_ruid nieuwe ontwikkelingen) op het forum). Misschien dat iemand hier nog een toelichting op kan geven?

Trouwens, jij nog een uurtje BSD-tijd voor me deze week?

Ok duidelijk. Die 'ellende' blijft ook zonder mod_ruid binnen de perken, de enige reden dat het mij interessant lijkt is wat rechten-issues voorkomen (bestandjes die van apache zijn en niet meer verwijderd kunnen worden, dat soort gedoe).

En, je weet me te vinden ;-)

Ik heb het nu ook thuis om mijn testbak draaien, maar ik had daarstraks een script waarvan ik de map eerst 771 moest chmodden anders bleef ik filepermissie fouten krijgen. Als ik een whoami doe op de browser geeft hij wel de goede gebruiker aan.

Blijf je dat toch houden bij sommige scripts? Of heb ik iets in de config verkeerd staan?

Oorspronkelijk geplaatst door wdv

Randy, in hoeverre baken jij af dat de functionaliteiten van mod_ruid niet misbruikt worden om root te worden? Denk aan het risico van Apache exploits (momenteel geen issue natuurlijk, maar wat als er een 0-day exploit toegepast wordt, gefocussed op mod_ruid users?), of misbruik van de POSIX functies van PHP.

Van het feit dat de php posix functies zijn te misbruiken heb ik nooit bewijs gezien (kan naar mijn mening ook niet).
De enige echt grote blunder die je met php kan maken is het toestaan van de dl() functie op een server met mod_ruid. Je kan dan een module uitvoeren waarmee je in no time root bent.
Een 0-day exploit is een risico, maar dit kan je met bv. SElinux aardig afschermen.