visualight
18/11/2006, 20h52
"Chrooter" PostgreSQL
Ce fut aussi simple que pour Perl, sauf que davantage de bibliothèques ont été requises. Dans l'ensemble, ce n'était vraiment pas difficile à faire. J'ai dû ouvrir PostgreSQL au réseau, mais seulement sur l'interface loopback. Comme il était "chrooté", les autres services "chrootés" n'y avaient pas accès, comme par exemple le serveur apache. J'ai compilé Perl dans PostgreSQL et j'ai dû ainsi ajouter beaucoup de choses concernant Perl dans mon fichier de configuration.
Source: ftp://ftp.us.postgresql.org/source/v...l-7.1.3.tar.gz
Compilez et installez postgres sur votre système dans /usr/local/postgres. Utilisez ensuite le script Perl.
"Chrooter" Sendmail
Exécutez mon script.
Maintenant, est-ce qu'il reste des inconvénients ? Oui. Il fonctionne toujours en tant que root. Malédiction ! De plus, certains fichiers sont recréés par /etc/rc.d/init.d/sendmail lorsqu'il est démarré. Mon script ne gère pas cela. Chaque fois que vous modifiez sendmail dans /etc/mail, copiez les modifications dans /chroot/sendmail/etc. De même /var/spool/mail devra pointer vers /chroot/sendmail/var/spool/mail de façon à ce que sendmail et les utilisateurs (quand ils se connectent) puissent voir les mêmes fichiers.
Le bon côté c'est que vous pouvez toujours envoyer du courrier, ce n'est que la réception qui pose un problème. Ainsi, j'ai pu installer sendmail avec apache sans difficulté. Certains de mes scripts Perl expédient du courrier et j'avais donc besoin que les fichiers sendmail soient copiés dans la zone "chrootée" d'apache.
D'autres choses à "chrooter".
Voici ma philosophie :
1. Tout devrait être "chrooté", y compris sendmail, ssh, apache, postgresql, syslog, et tous les services actifs sur l'ordinateur.
2. Tout devrait se trouver sous un compte non root (il est possible que vous soyez obligé de rediriger des ports protégés vers un port non protégé). C'est d'ailleurs valable pour sendmail et syslog.
3. Les logs devraient être envoyés à l'extérieur.
4. Une partition devrait être définie pour chaque service pour limiter l'espace disque qu'un pirate est susceptible d'utiliser s'il décide d'y écrire. Vous pourriez utiliser une interface loopback pour monter des fichiers en tant que système de fichier pour certains de ces services en cas d'insuffisance du nombre de partitions.
5. Root devrait être propriétaire des fichiers qui ne changent pas.
Pour ce qui concerne sendmail et syslogd, je persiste à croire qu'il pourrait être exécutés sous un compte non root. Pour sendmail, ce devrait être possible mais j'ai trouvé extrêmement difficile de l'exécuter sous un compte non root. Je n'y suis pas parvenu et je pense que c'est une grave erreur de ne pas pouvoir y arriver. Je sais que ça pose des problèmes, mais je crois qu'il faudrait penser à les résoudre. Puisqu'il est possible de gérer les permissions je ne vois pas pourquoi sendmail doit être exécuté en tant que root. Il y a sans doute des raisons que je ne perçois pas, mais je doute qu'on ne puisse pas surmonter les obstacles.
Pour syslog, je n'ai même pas essayé, mais je dirais que ces logs devraient être possédés par un compte non root et je ne vois pas pourquoi ce ne serait pas possible. Au moins, j'ai réussi à ce que syslog soit "chrooté" pour chaque service.
Tous les services devraient être installés sous des comptes non root. Même NFS. Tout.
Suggestions
* Utiliser deux logins pour ssh et prévoir deux démons sshd actifs.
* Trouver comment exécuter sendmail ou d'autres programmes de courrier sous des comptes non root.
* Supprimer les bibliothèques inutiles dans /lib. J'ai tout copié par paresse. Vous n'avez pas besoin de la plupart.
* Traiter les logs de syslogd en externe et voir si on peut lier syslogd à un port réseau et faire que tous les services se connectent à ce port réseau par l'interface loopback. Voir s'il est possible d'exécuter syslogd sous un compte non root.
Conclusion
Je pense que chroot est une bonne chose pour tous les services. Je crois que c'est une grave erreur de ne pas "chrooter" tous les services sous des comptes non root. J'aimerais que les distributions majeures le proposent, ou une distribution moins connue : n'importe laquelle. Mandrake a commencé en améliorant des choses de RedHat, peut-être que d'autres pourraient prendre des choses à Mandrake et améliorer chroot. Rien n'empêche quelqu'un de refaire le travail de quelqu'un d'autre dans le monde GNU/Linux, donc ce doit être réalisable. Si une société se décidait à tout "chrooter" et à créer un environnement simple permettant aux utilisateurs de gérer leurs services "chrootés", elle aurait une distribution fantastique ! Maintenant que Linux se répand, les gens ne veulent plus voir la ligne de commande, donc si tout est fait du côté de l'interface, ils n'ont plus à voir les entrailles et n'ont plus besoin de savoir ce qu'il se passe -- ils ont seulement besoin de configurer l'ensemble et de savoir que ça fonctionne !
Je suis à 100% pour l'idée que tous les services devraient être "chrootés" sous des comptes non root et qu'une distribution qui ne propose pas cette possibilité est impropre à l'utilisation dans un environnement de production.
Ce fut aussi simple que pour Perl, sauf que davantage de bibliothèques ont été requises. Dans l'ensemble, ce n'était vraiment pas difficile à faire. J'ai dû ouvrir PostgreSQL au réseau, mais seulement sur l'interface loopback. Comme il était "chrooté", les autres services "chrootés" n'y avaient pas accès, comme par exemple le serveur apache. J'ai compilé Perl dans PostgreSQL et j'ai dû ainsi ajouter beaucoup de choses concernant Perl dans mon fichier de configuration.
Source: ftp://ftp.us.postgresql.org/source/v...l-7.1.3.tar.gz
Compilez et installez postgres sur votre système dans /usr/local/postgres. Utilisez ensuite le script Perl.
Code:
cd /chroot # Supprimez le commentaire de la ligne suivante si vous n'utilisez pas mon fichier de configuration. # ./Config_Chroot.pl config postgres ./Config_Chroot.pl install postgres ./Config_Chroot.pl start postgres
"Chrooter" Sendmail
Exécutez mon script.
Code:
cd /chroot # Supprimez le commentaire de la ligne suivante si vous n'utilisez pas mon fichier de configuration. # ./Config_Chroot.pl config sendmail ./Config_Chroot.pl install sendmail ./Config_Chroot.pl start sendmail
Le bon côté c'est que vous pouvez toujours envoyer du courrier, ce n'est que la réception qui pose un problème. Ainsi, j'ai pu installer sendmail avec apache sans difficulté. Certains de mes scripts Perl expédient du courrier et j'avais donc besoin que les fichiers sendmail soient copiés dans la zone "chrootée" d'apache.
D'autres choses à "chrooter".
Voici ma philosophie :
1. Tout devrait être "chrooté", y compris sendmail, ssh, apache, postgresql, syslog, et tous les services actifs sur l'ordinateur.
2. Tout devrait se trouver sous un compte non root (il est possible que vous soyez obligé de rediriger des ports protégés vers un port non protégé). C'est d'ailleurs valable pour sendmail et syslog.
3. Les logs devraient être envoyés à l'extérieur.
4. Une partition devrait être définie pour chaque service pour limiter l'espace disque qu'un pirate est susceptible d'utiliser s'il décide d'y écrire. Vous pourriez utiliser une interface loopback pour monter des fichiers en tant que système de fichier pour certains de ces services en cas d'insuffisance du nombre de partitions.
5. Root devrait être propriétaire des fichiers qui ne changent pas.
Pour ce qui concerne sendmail et syslogd, je persiste à croire qu'il pourrait être exécutés sous un compte non root. Pour sendmail, ce devrait être possible mais j'ai trouvé extrêmement difficile de l'exécuter sous un compte non root. Je n'y suis pas parvenu et je pense que c'est une grave erreur de ne pas pouvoir y arriver. Je sais que ça pose des problèmes, mais je crois qu'il faudrait penser à les résoudre. Puisqu'il est possible de gérer les permissions je ne vois pas pourquoi sendmail doit être exécuté en tant que root. Il y a sans doute des raisons que je ne perçois pas, mais je doute qu'on ne puisse pas surmonter les obstacles.
Pour syslog, je n'ai même pas essayé, mais je dirais que ces logs devraient être possédés par un compte non root et je ne vois pas pourquoi ce ne serait pas possible. Au moins, j'ai réussi à ce que syslog soit "chrooté" pour chaque service.
Tous les services devraient être installés sous des comptes non root. Même NFS. Tout.
Suggestions
* Utiliser deux logins pour ssh et prévoir deux démons sshd actifs.
* Trouver comment exécuter sendmail ou d'autres programmes de courrier sous des comptes non root.
* Supprimer les bibliothèques inutiles dans /lib. J'ai tout copié par paresse. Vous n'avez pas besoin de la plupart.
* Traiter les logs de syslogd en externe et voir si on peut lier syslogd à un port réseau et faire que tous les services se connectent à ce port réseau par l'interface loopback. Voir s'il est possible d'exécuter syslogd sous un compte non root.
Conclusion
Je pense que chroot est une bonne chose pour tous les services. Je crois que c'est une grave erreur de ne pas "chrooter" tous les services sous des comptes non root. J'aimerais que les distributions majeures le proposent, ou une distribution moins connue : n'importe laquelle. Mandrake a commencé en améliorant des choses de RedHat, peut-être que d'autres pourraient prendre des choses à Mandrake et améliorer chroot. Rien n'empêche quelqu'un de refaire le travail de quelqu'un d'autre dans le monde GNU/Linux, donc ce doit être réalisable. Si une société se décidait à tout "chrooter" et à créer un environnement simple permettant aux utilisateurs de gérer leurs services "chrootés", elle aurait une distribution fantastique ! Maintenant que Linux se répand, les gens ne veulent plus voir la ligne de commande, donc si tout est fait du côté de l'interface, ils n'ont plus à voir les entrailles et n'ont plus besoin de savoir ce qu'il se passe -- ils ont seulement besoin de configurer l'ensemble et de savoir que ça fonctionne !
Je suis à 100% pour l'idée que tous les services devraient être "chrootés" sous des comptes non root et qu'une distribution qui ne propose pas cette possibilité est impropre à l'utilisation dans un environnement de production.