bon je voudrais en klr sur une machine chrooter
exim  
bind(deja fais)
apache (perl + php)
mysql
ssh(deja fais)
 
le probleme c est que tres peu de howto existe et que quand il s existe son inadapté pour moi
donc si vous avez des infos et des bons howto et que vous avez deja fais cela votre aide est la bien venu
 
ayant peu de connaissance sur chroot je me pose c'est petite question aussi
-que vais je perdre en fonctionnalité et service
-et quel sont les disfonctionnements que je pourrais rencontrer
 
 
merci...

up  
 
personne a une aide ?

Bonjour,
 
 Je suis justement tombé sur un howto très bien fait pour chrooté un serveur apache avec modules SSL.
 
http://www1.securityfocus.com/focu [...] -inst.html
 
La commande vraiment indispensable lorsque l'on veut chrooté est: ldd . Elle va lister les librairies partagées que réclame l'exécutable pour fonctionner.
 
Pour ce qui s'agit de perdre des fonctionnalités ou services. Tout dépend de ce que tu entends par là.Si tu configure et compile tout puis que tu copie dans ton répertoire chrooté,tu ne perdras aucune fonctionnalité. L'important étant que tout ce dont tes serveurs est besoin se trouve dans l'environnement chrooté.
 
Bonne chance ,
 
Zak  
   

oui mais en fait c po tellement la technique c est plutot une experience avec probleme de commmunication entre les different service et autre et si c viable aussi que je cherche
 
mais merci quand meme c tjrs bon a prendre

Ah ok    
 
Je n'ai fait un chroot que sur apache avec mod_perl et ca marche nickel. J'essaie aussi de chrooté htdig mais j'ai un peu de mal à lui faire créer ses bases en environnement chrooté     .
Je n'ai remarqué aucun changement de comportement de mon serveur apache suite au chroot. Mais c'est un petit serveur  
 
Bye,
 
Zak
 
 

moi se sera assez consequent j aurais besoin de php qui lui meme aura besoin de openldap imap pop mysql
donc je me pose des questions sur le bon fonctionnement avant de mettre en service

Perso j'ai abandonne le chroot depuis que systrace existe.
systrace est en quelque sorte un firewall pour les softs.
 
Tu installes ton systeme et tes serveurs tout a fait normalement, tu les lances avec systrace, et tu les laisses tourner un peu. Ca va te generer tout seul des fichiers de regles en fonction de ce que tes programmes ont fait. Tu y jettes un rapide coup d'oeil, puis tu relances ces demons en leur defendant de faire quoi que ce soit qu'ils n'aient pas fait dans le passe. Et hop... super secure, super simple...
 
http://www.citi.umich.edu/u/provos/systrace/

merci axey j attendais une reponse de ta part en fait
car j ai vu que t competence etait excellente dans ce domaine
 
merci pour cette info car avec le chroot je craignait de perdre des fonctionnalites a cause de la securite mais systrace ca a l air d etre bien fait
 
merci encore
 

Systrace is currently available only for OpenBSD and NetBSD. However, the design and implementation is very portable. If you are interested in porting the kernel part to FreeBSD or GNU/Linux, please let me know. Some work has started on a GNU/Linux port
 
 
snif snif c est service sont sur gnu/linux ...  
 
chez moi

ptit up de l apres midi

up du matin calin

Tu peux indiquer sur quel os est ta machine asphro et où tu as trouvé le tuto pour chrooter bind stp ?

http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html

Lui je le connais oué, mais je voulais savoir si asphro utilisait celui-ci et sous quel os il tourne

une petite question d'un ignare comme moi dans ce domaine : c'est quoi l'intérêt de chrooter un service qui tourne pas en root, qui a un user dédié pour son exécution, qui a des règles bien définies en ce qui concerne les droits ?
Parce que je m'y étais intéressé aussi, mais j'ai abandonné l'idée, j'avais l'impression que ce n'était pas utile
 
sinon, pour la communication, si tu sépares pas les services, y-a pas de raison qu'il y ait de problème
si tu les sépares, tu pourras les faire communiquer sans problèmes via des sockets tcp/udp (si il le permettent tous, ce dont je suis pas sur, et si tu n'as pas un firewall qui empeche les communications sur localhost). Si c'est via des socket unix, tu auras plus de pb, forcément  

c simplement une coucbe de sécurité en plus, apres avoir la derniere version du service, mettre les bons droits sur les fichiers, vérifier les privileges des users, vérifier qu'aucun setuid ne traine sur le disk, politique firewall, politique logs, etc etc

pis bon le DNS c quand meme hyper important, si tu arrive a corrompre d'une maniere ou d'une autre des correspondances ip<->nom  imagine ce que tu peut faire des services dépendants du dns....quasiment tous utilisent la résolution d'ip

 
oui, je viens de voir un exemple dans la doc de mysql lorsqu'on utilise des jokers.
genre, autorisé tout ce qui vient de 123.222.111.%
et le % peut aussi bien representer un nombre compris entre 0 et 255 (ce qui est attendu ici), qu'une chaine alphanumérique du genre 'grosconnard.com'. Où le gros connard peut du coup, via l'adresse 123.222.111.grosconnard.com (facile à obtenir), s'introduire sur ton pc et exécuter ce qui est autorisé des les règles prédéfinies
mais je comprends pas ce qu'il pourrait faire de mal si c'est règles ont été bien défini (je veux dire, que peut-il bien faire de plus sans chrootage qu'avec ?)

attends, je capte pas comment tu fait pour passer d'une query SQL a lancer une commande sur le systeme ??

monokrome a écrit a écrit : attends, je capte pas comment tu fait pour passer d'une query SQL a lancer une commande sur le systeme ??

 
ouai, j'ai été un peu vite là
il pourra lire et écrire ce que lui autorise les règles définies (ça peut aller loin si c'est mal défini), mais y-a pas de raison que chrooter mysql sécurise plus la chose ? (je m'exprime p-t mal, mais je comprends pas bien là)

ca sert surtout a mon avis a limiter la "portée" des fichiers auxquels le daemon peut avoir acces, la il a juste ce qu'il lui faut, alors que si demain on trouve un moyen d'envoyer des commandes au deamon, on pourra lire les /etc, ce qui se passe dans /proc (processus), alors que la, chrooté, il y a juste les fichiers de zones et 3 pauvres libs

 
ah ouai, exact  

 
celui la et slackware

le but est si une faille est trouve et dans un service et que l utilisateur a le moyen par le biais d une faille d un service de se retrouver root il se concatener au petit environement chroot avec tout juste de mo pour uploarder un fichier texte et  
qq librairie et le demon du service
 
 
et c est aussi pour apprendre a chrooter les service

asphro a écrit a écrit : le but est si une faille est trouve et dans un service et que l utilisateur a le moyen par le biais d une faille d un service de se retrouver root il se concatener au petit environement chroot avec tout juste de mo pour uploarder un fichier texte et   qq librairie et le demon du service     et c est aussi pour apprendre a chrooter les service

 
 
ouai, je suis d'accord, sauf sur un point : on ne se retrouve pas root par hasard (je n'affirme pas, je suis pas sur, je ne demande qu'à ce qu'on m'éclaircisse la chose), si ton service est démarré avec un utilisateur non-root, l'exploitation de cette faille ne permettra pas grand chose

au pire des cas biensure perso j ai jamais vu , mais bon ..
 
le but en securite c de faire face au pire de tout les cas,
meme si certains diront c IMPOSSIBLE moi je repondrais plutot tout est possible

c comme je l'ai dit avant une protection en plus...y a plein de choses a faire en plus, une erreur souvent commise est de faire tourner tous les services en nobody, a ce moment la plus il fait tourner de services plus il a de droits..

asphro a écrit a écrit : au pire des cas biensure perso j ai jamais vu , mais bon ..   le but en securite c de faire face au pire de tout les cas, meme si certains diront c IMPOSSIBLE moi je repondrais plutot tout est possible

 
oui, c'est l'approche à suivre

 
l'idéale c'est de créer un nouvel utilisateur pour chaque service à mon avis

chez moi il n y a po de nobody chaque demon a son user j ai aplique aussi le patch grsecurity j ai ete en low je viens de lire un peu de doc et sur ce patch et j essaye de le passer en customised..
 
bon je vais faire joujou avec ca
 
note j ai chrooter apache + php (sans rell diffculté apres avoir lu pas mal de hosto sur le principe du chroot) je vais passer a mysql et exim d ici peut et voir ceux que ca donne dans un environnement de production et de fonctionnalité

exactement, perso g mysql pour mysql, www pour apache, bref riend e tres original...et bien sur pas de shell pour ces utilisateurs de leur home c leur jail

 
en fait c vrai que c tout con, deja repérer tous les fichiers de conf du services, recréer une arborescence bidon, un coup de ldd sur les différents binaires du service, recopier les libs et basta

ben oui je croyais ct complique avant mais j ai lu 2-3 truc sur le chroot de certain service et c toujours service mais le probleme c est la perte de fonctionnalité
 
enfin faut choisir securite ou fonctionnalité

oui bon c est ce que je craignais impossibilte apache+php de communique avec mysql chrooter ou pas
il faut chrooter mysql dans la memem prison que apache (ca perd de son sens)
 
en plus j aurais besoin de mysql pour d autre service et je crains de chrooter c service dan sla meme prison que apache
 
donc ...
 
a moins que je me suis planter qq part mais je pense pas
 
edit: enfait me suis planter j ai oublier de mettre l user dans la base mysql

asphro a écrit a écrit : oui bon c est ce que je craignais impossibilte apache+php de communique avec mysql chrooter ou pas il faut chrooter mysql dans la memem prison que apache (ca perd de son sens)   en plus j aurais besoin de mysql pour d autre service et je crains de chrooter c service dan sla meme prison que apache   donc ...   a moins que je me suis planter qq part mais je pense pas   edit: enfait me suis planter j ai oublier de mettre l user dans la base mysql

 
alors là j'ai pas essayé mais tu me surprends
si tu les fait communiquer par port tcp y-a pas de raison que ça déconne ?!    
 
tu peux me dire comment tu as fait ton test ?
 
EDIT : et ça marche alors ?

non mais mysql c ok now
 
par contre c zarb en mode chrooter impossible de se connecte sur localhost quand je mais locahost par contre si je mais "boumkers"
nom de la meme machine ca marche ou 127.0.0.1 ca marche ya  que locahost qui veut po je comprend po

 
ah ouai, c'est louche ça, localhost, c'est un alias pour 127.0.0.1, bizarre ...
m'enfin si ça marche tant mieux  

oui ca marche sinon enfait ca le fais aussi en non chrooter c zarb ca

il te manquerai pas ton /etc/hosts dans ta prison toi ? c dedans que sont définis les alias reseau

nono y a tout si ca marche avec l alis boumkers
 
mais meme en non chrooter il veut po de localhost je vois po pkoi
 
peut etre un bleme avec le patch grsecurity mais ca metonnerai
 
vais tenter avec le noyau non patcher