On 31 Jul 2002, Jean-Bruno Luginbühl wrote: > exemple. Là je dois avouer ma faiblaisse quand au droit Unix, car j'ai > le droit de entrer dans le répertoire (x), mais pas le droit lecture > (r). Cela signifie que l'on ne peut pas lister, mais tout de même > exécuter un fichier ayant les droits idoines dans ce répertoire ?
man 2 chmod # donne les différentes permissions ainsi que: http://www-internal.alphanet.ch/~schaefer/unixguide/unixguide_html/node78.html Pour une explication plus détaillée de chacun des drapeaux/bits de permission, voir: http://esnig5.cpln.ch/~esnig/CVS/cours_linux/cours/cours_400/RELEASES/2002-02-18/slides.ps.3.pdf plus précisément dès la page 3. > Bien, mais quel est l'avantage de suid? C'est de lancer un prog comme > utilisateur et que le programme soit en fait lancé en root? C'est le concept de base d'augmentation de privilège d'UNIX. Pendant l'exécution d'un programme suid (respectivement sgid), l'utilisateur (respectivement le groupe) effectif (celui qui exerce ses droits) change pour prendre celui du propriétaire (respectivement du groupe) du fichier. Un cas particulier est dans le propriétaire est root et que le bit suid est positionné. Dans ce cas l'on peut, pendant l'exécution du programme, toucher à des données modifiables/lisibles que par root (p.ex.: commande passwd et fichier /etc/shadow). > > machine et de les restreindre à un groupe donné, genre `pingok', > > `suok', etc. Ainsi en cas d'exploit -- en particulier sur une machine > > réellement multiutilisateur au niveau d'UNIX -- on est tranquille. > > Et comment fait-on cela ? C'est l'exercice 2 page 17, dont le corrigé est sous: http://esnig5.cpln.ch/~esnig/CVS/cours_linux/cours/cours_400/RELEASES/2002-02-18/droits.pdf > C'est juste, ils sont créé par l'utilisateur final. Mais le problème est > de pouvoir y avoir accès, même si l'on est pas l'utilisateur en > question. Par exemple de pouvoir pour mon père de créer un document dans Plusieurs solutions, qui en général impliquent la connexion avec le bon utilisateur et l'utilisations de masques forcés dans la configuration de Samba. Mais pour donner plus de détails il faudrait encore savoir quel est le problème ? > père travail avec W98 et on ne peut pas attribuer des droits. Je sais je Une alternative est d'installer un système de fichiers supportant les ACL (Access Control List, voir aussi les slides du cours sécurité ci-dessus). Notamment ext3+acl et xfs supportent cela. On peut ensuite installer une version de Samba `acl-aware' et configurer les droits d'accès depuis les ACLs de Windows (menu propriété). > > daemon NFS, probablement inutile, supprimer. > > ben je travail sous linux moi, je veux pas me connecter au serveur par Ce n'était pas clair: le serveur s'appelant `ntsrv', je pensais que cette machine ne s'occupait que de servir des fichiers pour machines NT Windows. Si vous avez besoin de NFS car vous avez des clients Linux ou UNIX (et c'est la seule solution encore aujourd'hui qui implémente un système de fichiers réseau vaguement POSIX sous Linux), évidemment vous avez besoin de ces services. A vous d'établir la liste des services utiles et de supprimer ceux qui ne le sont pas. > TRES long pour afficher quoi que ce soit. Seul moyen que j'ai trouvé > rebooter la machine.... :( Je suis ouvert à tout smbfs n'est pas de très grande qualité. > > Je l'accorde qu'en local c'est en général moins risqué, mais. > > Mais quoi????.... Ca y est j'ai des cheveux blanc! ;) Bon, je vais > regarder les logs, et ce par la console sur le serveur lui-même. Il y a eu des cas où des virus Windows importés dans le réseau local attaquaient spécifiquement des machines Solaris non patchées (vu qu'en réseau privé d'entreprise, hein, à quoi ça sert d'assurer une certaine sécurité ?) Mais bien sûr, la sécurisation prend du temps. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
