theocrite Posté(e) le 27 septembre 2004 Partager Posté(e) le 27 septembre 2004 Rem : Je n'ai aucun problèmes. Mais merci pour l'info. Il se peut que ça me serve rapidement. Ah ! Intéressant WebDAV donc. Et est-ce que l'utilisateur peut se retrouver loggué avec son compte plutôt que celui d'apache ?Je ne me suis pas posé la question, mais vu que ça passe par apache, je ne pense pas. Je ne vois pas apache s'autentifier autrement.Oui, alors ça je suis contre. Si on a fait des ports dans le protocole TCP, c'est pas pour les chiens.Oui, mais le problème, c'est que webdav est une extention, du protocole HTTP1.1.Avec WebDAV et XML-RPC qui se multiplient, le port 80 va devenir une vraie poubelle, et le firewall servira plus à rien. On peut pas filtrer sur les ports si tout passe par le même.C'est déjà beaucoup le cas je trouve. Beaucoup de choses passent par le port 80. Bientôt le filtrage de contenu ?Comment ça se fait que je ne sois pas surpris... Pour être tout à fait honête, ça ne merdouille qu'avec certaines versions et je crois que c'est corrigé. Mais bon, le nombre de mails qu'on a reçut. Pourquoi ça ne fonctionne pas ? Blablabla. La feinte du renard, c'est de s'autentifier normalement => accès refusé, on se réautentifie et on clique sur annuler, et on est connecté :reflechi:Crois moi, j'ai encore de quoi ne pas t'étonner. Lien vers le commentaire Partager sur d’autres sites More sharing options...
-rem- Posté(e) le 27 septembre 2004 Auteur Partager Posté(e) le 27 septembre 2004 ben il suffit de modifier quelques droits sur les fichiers, pour que tu ne puisse pas les lire, quelque soit ton shell. Lien vers le commentaire Partager sur d’autres sites More sharing options...
gauret Posté(e) le 27 septembre 2004 Partager Posté(e) le 27 septembre 2004 ben il suffit de modifier quelques droits sur les fichiers, pour que tu ne puisse pas les lire, quelque soit ton shell. Oui, mais /etc/passwd, je pense qu'il doit être en lecture pour tout le monde :) Pour ce qui est de WebDAV, c'est dans la FAQ de mod_dav, c'est pas possible d'avoir des droits différents du process apache, donc dommage, c'est pas encore ça le top... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Skippy380 Posté(e) le 3 octobre 2004 Partager Posté(e) le 3 octobre 2004 Je vais vous parler d'une version de Linux destinée à la sécurité : SELinux. Je ne vais pas expliquer comment l'installer, pour celà je vous renvoie au site de gentoo (par exemple) : http://www.gentoo.org/proj/en/hardened/sel...86-handbook.xml Par contre, je vais vous expliquer un peu ce que SELinux propose, pourquoi et comment. Je ne pourrais bien sûr pas tout dévoiler ici, d'autant plus que je ne connais pas tout, mais je vais essayer de donner un bon aperçu pour ceux qui se demandent ce qu'apporte SELinux et pourquoi. Ce que SELinux Rajoute SELinux définit un certain nombre de nouveaux attributs : Les types sont des attributs de sécurités qui concernent les fichiers, les ports, les peripheriques ... Le type d'un process est appelé son domaine. Les politiques de sécurité de SELinux permettent de renforcer les regles décrivant les interactions entre les objets ou entre les domaines selon leur type. Un type est suffixé par "_t" comme par exemple sysadm_t. C'est l'attribut le plus important. Les roles concernent les utilisateurs. Ils permettent d'en limiter les actions possibles, mais ils ne sont pas fixes. Pour administrer le système, le role sera "sysadm_r", alors qu'une utilisation normale se fera avec le role "staff_r". Si un role n'a pas le droit d'accéder à un certain domaine, l'action qu'il tentera sera rejetée. L'utilisateur peut cependant être changé temporairement de role pour effectuer une action. Un role est suffixé par "_r". Les identités ressemblent fortement aux noms d'utilisateurs sous Linux, mais ils ne sont pas censés changer. L'interet est de s'affranchir de la dangereuse fonction setUID. L'utilisateur ne peut pas changer d'identité, mais seulement de role. Chaque identité à une certaine liste de roles qui lui sont accessibles. Un context est l'alliance des trois attributs précédent, par exemple "system_u:object_r:bin_t". Si l'on fait un ls -l, on obtient : drwxr-xr-x root root system_u:object_r:bin_t bin drwxr-xr-x root root system_u:object_r:boot_t boot drwxr-xr-x root root system_u:object_r:device_t dev On voit qu'il y a toujours les permissions habituelles, mais aussi le contexte du repertoire. Il en est de même pour un ps. Les politiques généralement définies dans les fichiers situés dans /etc/security/selinux/src/policy contiennent toutes les définitions concernant la sécurité, en particulier les attributs présentés au dessus. Il existe un certain nombre de macros permettant de créer simplement ces politiques. A quoi ca sert ? Toutes ces modifications s'accompagnent d'un grand nombre de patchs modifiant le noyau pour améliorer la sécurité. On note tout d'abord qu'il n'est plus nécessaire d'avoir un utilisateur root possédant les pleins pouvoirs. Le but est qu'à tout instant, chaque utilisateur et chaque processus n'aie pas plus de droits qu'il n'en a besoin. Cela permet de faire tourner en toute sécurité des programmes auxquels on ne fait pas totalement confiance (aussi bien au niveau de la stabilité que de la sécurité). La sécurité du systeme ne dépend plus que sur la fiabilité du code du noyau (et des patchs), et de la configuration des politiques de sécurité, alors que sous une version classique de Linux, la sécurité dépend aussi des processus privilégiés. Et si je veux en savoir plus ? Je conseille la documentation de la version Gentoo SELinux : http://www.gentoo.org/proj/en/hardened/sel...86-handbook.xml Mais aussi le site de SELinux : http://www.nsa.gov/selinux/ Lien vers le commentaire Partager sur d’autres sites More sharing options...
gauret Posté(e) le 3 octobre 2004 Partager Posté(e) le 3 octobre 2004 MERCI Skippy380 !!! Pour info, SELinux sera installé par défaut dans la Fedora Core 3, avec une politique assez souple pour ne pas paumer les utilisateurs. Je rajoute mes liens sur SELinux : http://sourceforge.net/docman/index.php?group_id=21266 http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ Avec SELinux, plus de transpiration quand on installe bind :) Lien vers le commentaire Partager sur d’autres sites More sharing options...
-rem- Posté(e) le 18 décembre 2004 Auteur Partager Posté(e) le 18 décembre 2004 Je m'occupe de ce topic tres prochainement. Je reprends ce tutoriel certainement pednant les vacances, mais je veux aussi pouvoir prendre le temps de revoir certaines manip assez pointues histoire de faire un truc complet, qu" on ne dise pas apres que rem fait des tutos creux... Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 18 décembre 2004 Partager Posté(e) le 18 décembre 2004 Je ne crois pas que quelqu'un aie pu dire ça Le topic sur les fstab est vraiment bien aussi, mais il y a pas mal de fautes. Là je suis un peut fatigué, je corrigerais un autre jour. Lors d'une install de serveur, on a utilisé un tuto vraiment très bien fait, très complet, fait par un français en plus : http://entreelibre.com/scastro/debian-secinst/ Je pense que ça mérite d'être donné en lien quelque part. Lien vers le commentaire Partager sur d’autres sites More sharing options...
-rem- Posté(e) le 18 décembre 2004 Auteur Partager Posté(e) le 18 décembre 2004 Fautes orthographe, oui je sais j'y suis allé assez vite sans me relire. Je devais faire ca cette aprem, mais je suis aller au resto puis on a pris un café, rentré 19h donc c'était tres juste. Des fautes techniques ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 18 décembre 2004 Partager Posté(e) le 18 décembre 2004 Heu non orthographe grammaire uniquement. Par contre il aurait peut être des trucs à rajouter. Mais je te ferais un post bien propre dans le bon topic avec tout ça quand tu auras fait tes corrections, comme ça j'arrète mon HS ici. Lien vers le commentaire Partager sur d’autres sites More sharing options...
-lsl- Posté(e) le 19 décembre 2004 Partager Posté(e) le 19 décembre 2004 salut tt le monde ! je viens de lire un peu les précautions pour la sécurité en local .... mais je comprend pas prquoi sudo est pref par rapport a su ? parce que on est oblige de taper le mot de passe root en su c'est ca ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Horus Posté(e) le 19 décembre 2004 Partager Posté(e) le 19 décembre 2004 Parce qu'avec su on se logge en super-user (admin?) jusqu'à ce qu'on pense à se déconnecter alors qu'avec sudo on "emprunte" les droits super-user uniquement le temps de la commande ---> pas de risque de continuer avec des droits inapropriés (et dangereux) Ps: Sauf si je me trompes... Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 19 décembre 2004 Partager Posté(e) le 19 décembre 2004 Sauf si tu fait "sudo su -" comme beaucoup de monde. L'avantage aussi de sudo la_commande, c'est que les logs ne sont pas chez le root, mais chez l'utilisateur de la commande (le bash history), c'est plus facile pour savoir qui à fait quoi. Parce que quand on doit appeller tout le monde pour savoir qui a fait une commande, pourquoi comment, c'est la galère (expérience désastreuse inside). Pour ne pas oublier de déconnecter le root, tu peux mettre un TMOUT=XXsecondes dans le bashrc ou le bash_profile du root. EDIT : par ailleurs, on peut coupler ça à un "export HISTFILE=/dev/null" pour le root, ce qui permet en cas d'attaque d'éviter que l'on sache les dernière opérations faites par le root. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sandeman Posté(e) le 19 décembre 2004 Partager Posté(e) le 19 décembre 2004 pis on peut bourrinement modifier le .bashrc de chaque user (à mettre dans le /etc/skel, donc) pour logger toutes les commandes tapées par tous les users. On avait fait ça y'a presque 10 ans dans notre salle Linux. J'ai plus la commande ne tête mais je peux retrouver ça... en tout cas ça nous a pas mal dépatouill". évidemment il faut que le .bashrc soit en 644 owné par root Lien vers le commentaire Partager sur d’autres sites More sharing options...
gauret Posté(e) le 19 décembre 2004 Partager Posté(e) le 19 décembre 2004 évidemment il faut que le .bashrc soit en 644 owné par root Si il est dans le répertoire perso du user, qu'est-ce qui l'empêche de faire un rm ~/.bashrc et d'en refaire un autre ? Son répertoire est pas chmod +t à ce que je sache, non ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
-lsl- Posté(e) le 22 décembre 2004 Partager Posté(e) le 22 décembre 2004 petite question : chmod est accéssible au simple user ....un simple utilisateur peut alors modifier lui même les droits sur des fichiers ? ( c'est pas possible ca quand même ?!) Lien vers le commentaire Partager sur d’autres sites More sharing options...
gauret Posté(e) le 22 décembre 2004 Partager Posté(e) le 22 décembre 2004 petite question : chmod est accéssible au simple user ....un simple utilisateur peut alors modifier lui même les droits sur des fichiers ? ( c'est pas possible ca quand même ?!) Bien sûr qu'il a le droit, c'est ses fichiers après tout, il en fait ce qu'il veut ! Mais il peut pas changer les droits si les fichiers ne lui appartiennent pas. Lien vers le commentaire Partager sur d’autres sites More sharing options...
-lsl- Posté(e) le 22 décembre 2004 Partager Posté(e) le 22 décembre 2004 merci pour la précision gauret !!!!! comme ca je ferais plus gaffe au groupe et au utilisateur ....... merci man !!!! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sandeman Posté(e) le 22 décembre 2004 Partager Posté(e) le 22 décembre 2004 il a même le droit de faire chmod -R 000 ~/* puis d'appeler root au secours (il faut toujours avoir un root de secours) parcequ'il peut plus rien faire ... Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 22 décembre 2004 Partager Posté(e) le 22 décembre 2004 Ben on a encore les droits dessus. theo@fermat:~/tests$ touch fichier theo@fermat:~/tests$ chmod 000 fichier theo@fermat:~/tests$ rm fichier rm: détruire un fichier protégé en écriture fichier régulier vide `fichier'? y theo@fermat:~/tests$ ls -l fichier ls: fichier: Aucun fichier ou répertoire de ce type theo@fermat:~/tests$ echo "test" > fichier theo@fermat:~/tests$ chmod 000 fichier theo@fermat:~/tests$ cat fichier cat: fichier: Permission non accordée theo@fermat:~/tests$ chmod 700 fichier theo@fermat:~/tests$ cat fichier test Lien vers le commentaire Partager sur d’autres sites More sharing options...
neuxneux Posté(e) le 2 mars 2005 Partager Posté(e) le 2 mars 2005 je relance le topic j'aimerais en particulier quelque chose sur le firewall intégré de mdk 10.1 (je crois pas en avoir besoin d'un autre vu que j'ai déjà un routeur firewall matériel) Lien vers le commentaire Partager sur d’autres sites More sharing options...
-rem- Posté(e) le 2 mars 2005 Auteur Partager Posté(e) le 2 mars 2005 Lorsque j'aurais le temps je le reprendrai, mais ca fait longtemps que je ne trouve plus le temps de le faire, et en plein demenagement actuellement, ce n'est pas pour tout de suite ( pas mars, ou vers fin mars ). Concernant le firewall Mandrake, pour ma part il en est hors de question car je n'utilise ni mandrake ni son firewall, le noyau linux en proposant un absolument parfait. Lien vers le commentaire Partager sur d’autres sites More sharing options...
lorinc Posté(e) le 2 mars 2005 Partager Posté(e) le 2 mars 2005 l'interface de firewall de mandrake n'est de toute façon qu'un frontend à iptables... Lien vers le commentaire Partager sur d’autres sites More sharing options...
neologix Posté(e) le 3 mars 2005 Partager Posté(e) le 3 mars 2005 Sur le firewall de Mandrake, il n'y a rien à dire. Pour peu que l'on sache lire... Autant faire un sujet sur iptables. neo Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.