Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 16/02/2019, à 01:33

Arbiel

Risques inhérents à la modification des droits fichiers système

Bonsoir

Dans une discussion que j'avais ouverte pour obtenir des informations sur l'"interdiction" d'exécuter des applications graphiques en mode administrateur, j'en suis arrivé à la conclusion que, pour modifier avec gedit des fichiers systèmes tels que /etc/fstab ou /etc/cryptab, il me suffisait de changer le groupe propriétaire de root à sudo, dont je suis le seul membre, et de donner le droit d'écriture sur ces fichiers au groupe propriétaire.

Il m'a alors été opposé que cette façon de procéder est le plus sûr moyen de diminuer la sécurité du système et d'avoir des problèmes allant jusqu'au blocage complet…

Je viens ici chercher des explications à cette affirmation dont je ne vois pas le fondement.

Lorsque je modifie le groupe propriétaire de ces fichiers de root à sudo, je deviens le seul utilisateur autorisé à modifier ces fichiers en mode utilisateur, c'est à dire avec une application graphique plutôt qu'en ligne de commande. Qui d'autre pourrait les modifier et selon quel stratagème ? Et si, dans un contexte d'entreprise, l'administrateur considère que certains membres du groupe sudo ne doivent pas bénéficier de ce droit, rien ne l'empêche de créer les groupes fstab … pour y inscrire les seuls utilisateurs habilités. Je ne vois vraiment pas en quoi, ce faisant, la sécurité du système peut être diminuée, sauf à ce que l'administrateur n'inscrive dans ces groupes des utilisateurs incompétents sur le sujet.

Et c'est, je le reconnais, par flemme, pour ne pas avoir à apprendre à utiliser un éditeur de texte en ligne de commande, que je procède ainsi. Mais pourquoi devrais-je m'astreindre à un tel apprentissage alors que je ne comprends absolument en quoi le recours à ce logiciel en mode administrateur serait plus sécurisé que celui de gedit en mode utilisateur ? Sauf à démontrer que l'utilisateur fait moins d'erreurs en ligne de commande qu'avec une application graphique. Mais je n'y crois pas trop lorsqu'il s'agit de modifier du texte, alors que c'est évidemment le cas pour des applications telles que nautilus, dans lesquelles un "glisser/déposer" malencontreux est plus probable que l'erreur correspondante en ligne de commande.

Quant à provoquer de problèmes pouvant aller jusqu'au blocage du système, je ne vois que des erreurs dans les fichiers modifiés. Mais la présence de telles erreurs dans le fichier modifié ne découle pas de l'exécution d'une application graphique en mode utilisateur plus que d'une commande en mode administrateur, mais d'une erreur de celui qui est derrière le clavier.

J'ai un peu l'impression que l'affirmation selon laquelle il ne faut surtout pas modifier les droits de quiconque sur les fichiers systèmes tient plus d'un postulat que de l'analyse réelle des situations rencontrées sur le terrain.

Je ne comprends pas pourquoi la modification des droits sur les fichiers systèmes, dans un contexte maîtrisé par l'administrateur, représente un risque sur la sécurité du système et augmente la probabilité de pannes.

Merci d'avance à quiconque pourra éclairer ma lanterne sur ce sujet.

Arbiel


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#2 Le 16/02/2019, à 04:07

Roschan

Re : Risques inhérents à la modification des droits fichiers système

Qui d'autre pourrait les modifier et selon quel stratagème ?

N'importe quel script lancé de manière plus ou moins consentie sous ton nom d'utilisateur. N'importe quelle mauvaise manip de ta part. Bref : tes fichiers sont vulnérables. Si tu ne comprends pas le principe d'une précaution de sécurité, et bien va, change toutes les permissions de ton système, elles ont sans doute été inventées pas des débiles qui s'y connaissent moins que toi après tout. Ou alors retourne sur Windows pour profiter de leur génial système de gestion des droits, et de la sécurité incroyable qui en résulte.

Oui je suis pas poli, mais en face de moi j'ai quelqu'un à qui on a expliqué plusieurs fois que gedit pouvait modifier les fichiers admin sans être lancé comme admin, simplement en en préfixant le chemin du fichier avec

admin://

, et la seule chose que tu en retiens c'est

Et c'est, je le reconnais, par flemme, pour ne pas avoir à apprendre à utiliser un éditeur de texte en ligne de commande, que je procède ainsi.

et

je ne comprends absolument en quoi le recours à ce logiciel en mode administrateur serait plus sécurisé que celui de gedit en mode utilisateur ?

On te demande juste de comprendre que tu peux utiliser gedit lancé en tant qu'utilisateur. Si tu ne comprends pas le reste, tant pis, c'est ton ordi que tu dégrades pas le mien, mais essaye au moins de comprendre ça.

J'ai la flemme de re-répondre au reste de ton blabla, c'est une discussion qu'on a déjà eu.

Hors ligne

#3 Le 16/02/2019, à 08:22

kholo

Re : Risques inhérents à la modification des droits fichiers système

salut,
les débutants peuvent utiliser nano que je trouve personnellement simple.
les seules restrictions sont

  • se déplacer avec les flèches

  • effacer les lignes caractère par caractère (pour ne pas avoir à apprendre un raccourcis)

  • se placer là où on souhaite coller

  • faire des copier coller avec ctrl + MAJ + c ou v

  • ctrl + x puis O (la lettre o) puis entrer pour fermer en enregistrant

ceci appris, l'utilisation de nano suffit pour les quelques modifications de fichiers systèmes

si le sudoer est apparu, c'est justement pour forcer les utilisateurs, seuls sur leur système, à prendre conscience quand ils sont dans un mode de droits supérieurs et être adapté à des systèmes mono utilisateur sur lesquels l'utilisateur prendrait trop facilement des droits élevés comme pourraient le faire n'importe quel programme ou script.
c'est une philosophie comme l'ont chaque OS et contourner cette philosophie est s'exposer à des risques...
quand un éditeur code un OS, il doit être généraliste et le modèle proposé correspond au plus grand nombre. Cela va de même sur ce forum. On nous laisse tout faire de notre système et, donc, on peut faire aussi des conneries... c'est pas pour autant qu'il faut le conseiller.

... et UN seul sudoer sur un système est une bonne stratégie. Même pour les mises à jour, il est préférable de trouver une stratégie pour que plusieurs utilisateurs puisse le faire que de leur donner le groupe sudoer.

pour aller plus loin, je suis partisan de la création de 2 comptes minimum (un sudoer et un avec des droits normaux) même sur les systèmes à un seul utilisateur... mais ça n'engage que moi... et je ne le fais pas systématiquement lol

Hors ligne

#4 Le 16/02/2019, à 08:43

grandtoubab

Re : Risques inhérents à la modification des droits fichiers système

Salut
Ces éditeurs en commandes sont tous affreux et pour un utilisateur ordinaire, comme moi, je pense qu'ils sont le plus sur moyen de tout péter.
Alors j'utilise par exemple,

gksudo gedit /etc/fstab

ça va faire maintenant une bonne dizaine d'années lol et je n'ai jamais eu de problèmes quoiqu'en disent les donneurs de leçons , pseudo-connaisseurs

on peut même s'amuser à restreindre l'utilisation complète des binaires sudo et gksudo aux membres du groupe sudo seuls, à la place de donner les droits d'exécution à tous

root@debian:~# cd /usr/bin
root@debian:/usr/bin# chown root:sudo sudo
root@debian:/usr/bin# chmod 4750 sudo
root@debian:/usr/bin# ls -al sudo
-rwsr-x--- 1 root sudo 136848 janv.  5 01:37 sudo

https://www.ssi.gouv.fr/uploads/2015/10 … ration.pdf
voir §7.2.2 sudo

Dernière modification par grandtoubab (Le 16/02/2019, à 08:53)


Linux tout seul sur HP Pavilion DV7 et Acer Aspire T650, Canon MG3650 en wifi
Debian 11 Bullseye Gnome/Xorg, Gnome/Wayland avec SDDM
https://bidouilledebian.wordpress.com/
ON M'A VU DANS LE VERCORS, SAUTER A L'ELASTIQUE..... J'AI DANS LES BOTTES DES MONTAGNES DE QUESTIONS....

Hors ligne

#5 Le 16/02/2019, à 10:50

Arbiel

Re : Risques inhérents à la modification des droits fichiers système

Bonjour

Je comprends parfaitement l'humeur de Roschan à mon égard car cela fait maintenant un à deux mois que je tourne autour de la question de l'utilisation d'applications graphiques, en l'occurrence gedit, en mode administrateur. Je me dois néanmoins de le remercier car il vient de m'ouvrir définitivement les yeux sur l'absurdité qui consiste à donner le droit en écriture sans contrôle sur des fichiers tels que /etc/fstab.

En effet, si dans un script, je supprime un fichier par la commande

rm "${fic}"

et que, par erreur, fic=/etc/fstab, …

Il ne faut donc pas modifier les droits des fichiers systèmes par simple convenance personnelle. J'en suis maintenant parfaitement convaincu.

Si quelqu'un veut bien le remercier de ma part, car je crains que, pendant un certain temps, il ne veuille plus perdre son temps à lire mon blabla. Et pour lui dire aussi que son franc parler ne me heurte absolument pas. Il a eu tout à fait raison de me remonter les bretelles.

Arbiel


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#6 Le 16/02/2019, à 12:22

kholo

Re : Risques inhérents à la modification des droits fichiers système

alleluia !!! lol

Hors ligne

#7 Le 16/02/2019, à 21:08

rogn...

Re : Risques inhérents à la modification des droits fichiers système

Roschan a écrit :

Oui je suis pas poli, mais en face de moi j'ai quelqu'un à qui on a expliqué plusieurs fois que gedit pouvait modifier les fichiers admin sans être lancé comme admin, simplement en en préfixant le chemin du fichier avec

admin://

Sans aucun appel à entrer le mot de passe, What the fuck ??????????????????????????????????????????????????????????????????????
Et c'est mis dans Ubuntu avec Gnome ce truc ???????????????????????? yikes yikes yikes