Bonjour.

Dans le cas où certains utilisateurs interagissent avec la machine, quelles sont les recommandations à apporter pour la protection des fichiers/process sensibles ?

Mes fichiers *importants* que je crée sont toujours en 740 (pour root:wheel). Mais je vois que certains par défaut ne sont pas comme ça, et sont accessibles en lecture par les "autres". Je pense à /etc/passwd, /etc/group.

Même si /etc/passwd ne contient pas les passwords, c'est quand même moyen d'afficher la liste des utilisateurs présents ? Par contre, certains daemons en ont besoin de cet accès en lecture. Je pense à Postfix qui a besoin d'un accès à /etc/group. Que pensez-vous de ce point ?

J'utilise aussi security.bsd.see_other_uids dans sysctl qui me semble indispensable.

Je fais aussi attention aux montages de mes partitions (noexec, nosuid). Mise en place de quota également.

Si vous avez des conseils, des suggestions, je suis preneur  8-)

Merci.

Elrohir wrote on 09. Aug 2009 at 18:47:

Bonjour. Dans le cas où certains utilisateurs interagissent avec la machine, quelles sont les recommandations à apporter pour la protection des fichiers/process sensibles ? Mes fichiers *importants* que je crée sont toujours en 740 (pour root:wheel). Mais je vois que certains par défaut ne sont pas comme ça, et sont accessibles en lecture par les "autres". Je pense à /etc/passwd, /etc/group. Même si /etc/passwd ne contient pas les passwords, c'est quand même moyen d'afficher la liste des utilisateurs présents ? Par contre, certains daemons en ont besoin de cet accès en lecture. Je pense à Postfix qui a besoin d'un accès à /etc/group. Que pensez-vous de ce point ?

Ben ls utilise aussi ces fichiers. Je ne pense pas qu'on puisse les cacher ou que ce soit utile en soit.


Quote:

J'utilise aussi security.bsd.see_other_uids dans sysctl qui me semble indispensable.

Oui mais ce n'est pas un mécanisme standard d'unix, à mon avis faut pas trop compter la dessus.

Sinon tu as regardé man security ?

Oui, ls(1) utilise /etc/passwd pour la conversion uid/name, et donc, en le rendant inaccessible, ça va afficher les uid à ceux n'y ayant pas accès. Moi, ça me convient. Mais après, ça peut être trop restrictif. Je n'aime pas trop que l'on puisse voir la liste des users de la machine (qui peut donner certaines indications). Après, si tout le monde fait comme ça et me dit que ce n'est pas bien grave, je m'en accommoderai.

Merci pour le man security, je ne connaissais pas, je vais lire ça attentivement !

Par contre, je n'ai pas compris ta remarque vis à vis de security.bsd.see_other_uids. En quoi le fait que ce ne soit pas unix-standard fait que l'on ne puisse pas trop compter dessus ? Moi, sur mon FreeBSD, ça me permet de masquer mes process aux autres users, et ça me plaît énormément (et ça marche bien).

Elrohir wrote on 10. Aug 2009 at 14:24:

Oui, ls(1) utilise /etc/passwd pour la conversion uid/name, et donc, en le rendant inaccessible, ça va afficher les uid à ceux n'y ayant pas accès. Moi, ça me convient. Mais après, ça peut être trop restrictif. Je n'aime pas trop que l'on puisse voir la liste des users de la machine (qui peut donner certaines indications). Après, si tout le monde fait comme ça et me dit que ce n'est pas bien grave, je m'en accommoderai. Merci pour le man security, je ne connaissais pas, je vais lire ça attentivement ! Par contre, je n'ai pas compris ta remarque vis à vis de security.bsd.see_other_uids. En quoi le fait que ce ne soit pas unix-standard fait que l'on ne puisse pas trop compter dessus ? Moi, sur mon FreeBSD, ça me permet de masquer mes process aux autres users, et ça me plaît énormément (et ça marche bien).

Le comportement standard c'est de permettre à tous de visualiser les processus et les paramètres. Ce qui fait qu'il ne faut JAMAIS passer des infos sensibles en paramètres.

Ceci même si on ne peut pas voir les autres processus. Ca peut-être une sécurité mais qui ne doit servir qu'au cas où, une sécurité ne devrait pas servir en règle générale à sécuriser, c'est en plus.

J'utilise aussi cette sysctl mais je ne compte pas dessus pour sécuriser la machine, c'est ce que je veux dire par là.

Sinon tu peux aussi utiliser les attributs de fichiers, avec les flag immuable et tout, couplés à des jails c'est vraiment puissant : tu peux avoir des jails qui ne peuvent pas modifier leurs fichiers tout en laissant l'hôte principal le faire (vu que chacun a son propre security level).

Tu as aussi le MAC framework :
http://www.freebsd.org/doc/en/books/handbook/mac.html

J'ai jamais joué avec si des gens ont des avis dessus ce serait intéressant.

Oui, c'est sûr que c'est bien pour "masquer" les process, mais ça s'arrête là. Ca ne dispense pas de ne pas mettre de passwords ou autres en paramètres.

Oui j'ai oublié de dire que j'utilise les flags avec chflags(1) et kern.securelevel, c'est assez pratique également.