Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

Old tired coder · Le 01/01/2022, à 13:02

Bonjour et bonne année 2022 à toutes et tous,

à la suite du crash de mon volume Debian-Xfce (ce qui fera peut-être l'objet d'un autre topic mais dans la section appropriée) j'ai lancé Ubuntu, ce qui m'a permis tout d'abord de constater que le problème n'est pas matériel, quoique... la vétusté de ma batterie est probablement à l'origine de mes ennuis.

Mais bref, voici ce qui m'a amené à ouvrir ce sujet :

Premier réflexe, j'ai commencé par sauvegarder mon "travail" récent (je suis retraité) en ouvrant sda3 (ma partoche Debian) et là, surprise : Nautilus ne me demande pas mon sudo.

C'est absolument inadmissible. Habituellement, c'est à partir de Debian que j'ouvre sda2 pour synchroniser mes données et là, les principes élémentaires de sécurité sont observés. Sans mon mot de passe admin, impossible d'accéder au volume.

J'ai hésité avant d'utiliser le terme "faille de sécurité" : après tout, si je n'ouvre pas de compte "invité" sous Ubuntu, mes données personnelles sont protégées. Mais qu'en est-il pour un attaquant extérieur ? Je n'ai pas l'âme d'un hacker mais je me fais fort de coder un script capable d'exploiter cette vulnérabilité sur toutes les bécanes en dual-boot où tournent Ubuntu et son bureau par défaut.

Dernière modification par cqfd93 (Le 02/01/2022, à 01:20)

FS · Le 01/01/2022, à 14:32

peut etre as tu partager ton répertoire Débian ?

Old tired coder · Le 01/01/2022, à 15:05

FS a écrit :

peut etre as tu partager ton répertoire Débian ?

Non, pas du tout : je suis un spécialiste de la sécurité retraité et je ne commettrai jamais une erreur pareille, même si je choppe l’Alzheimer, en admettant que l'on puisse partager un volume système. Il s'agit bien d'une vulnérabilité soit de Ubuntu, soit de l'éditeur de Nautilus, et peut-être des deux.

À ce propos, je ne créerai jamais un volume "/home" accessible à partir de plusieurs OS Linux, pour cette raison et pour pas mal d'autres. Tout ce qu'on peut faire logiquement, c'est partager un volume contenant des archives du genre "Cinéma, Musique, Culture, Littérature..." pour regrouper sur un même disque de simples fichiers très volumineux en un seul endroit.

Mais même ce genre de volume devrait être protégé par un mot de passe "admin", ne serait-ce que pour protéger les mineurs dans le cadre de l'informatique familiale.

[EDIT]
Ma partoche Debian a redémarré... Tout s'est bien passé, boot impeccable
[/EDIT]

Dernière modification par Old tired coder (Le 01/01/2022, à 16:06)

geole · Le 01/01/2022, à 16:21

Old tired coder a écrit :

Premier réflexe, j'ai commencé par sauvegarder mon "travail" récent (je suis retraité) en ouvrant sda3 (ma partoche Debian) et là, surprise : Nautilus ne me demande pas mon sudo.
C'est absolument inadmissible.

Bonjour et bonne année
Je ne suis pas surpris du comportement: La partition est montée, c'est parfait.
Maintenant, Si les données de cette partition ne n'appartiennent pas et que tu peux voir les noms de fichier, il y a problème.
Si les données t'appartiennent, il me semble logique que tu n'utilises pas sudo pur y accéder.

Old tired coder · Le 01/01/2022, à 17:21

geole a écrit :

Old tired coder a écrit :
Premier réflexe, j'ai commencé par sauvegarder mon "travail" récent (je suis retraité) en ouvrant sda3 (ma partoche Debian) et là, surprise : Nautilus ne me demande pas mon sudo.
C'est absolument inadmissible.
Bonjour et bonne année
Je ne suis pas surpris du comportement: La partition est montée, c'est parfait.
Maintenant, Si les données de cette partition ne n'appartiennent pas et que tu peux voir les noms de fichier, il y a problème.
Si les données t'appartiennent, il me semble logique que tu n'utilises pas sudo pur y accéder.

Bon raisonnement "humain" mais quid de la machine ?

En d'autres termes, crois-tu que ta machine sait si des données t'appartiennent ou non ?

Ubuntu a monté le volume de façon "transparente", sans information et encore moins de "prompt" et c'est ce comportement qui est inadmissible.

geole · Le 01/01/2022, à 18:55

Old tired coder a écrit :

Bon raisonnement "humain" mais quid de la machine ?
En d'autres termes, crois-tu que ta machine sait si des données t'appartiennent ou non ?
Ubuntu a monté le volume de façon "transparente", sans information et encore moins de "prompt" et c'est ce comportement qui est inadmissible.

Il parait que le système de base EXT4 est assez sécurisé, sinon on peut utiliser des ACL un peucomme windows avec le NTFS pour dédier les fichiers à leur utilisateur et le partager ou pas.
Le principe de base est la présence de trois groupes: Moi MesAmis LesAutres
et de quatre modes principaux d'accès: Aucun Lecture Ecriture Exécution
à allouer aux groupes
A titre d'exemple

a@a:~$ ls -ls /media/a | grep Test
 4 drwxr-xr-x 23 root root  4096 janv.  1 18:04 Test
a@a:~$ ls -ls /media/a/Test| grep TEST
     4 drwx------   2 syslog root      4096 janv.  1 18:08 TEST

l'utilisateur a n'a pas le droit d'accéder au répertoire TEST

Après avoir monté sans difficulté la partition, voici deux captures qui montrent que le répertoire est protégé et qu'il faut un mot de passe pour y accéder..
https://zupimages.net/up/22/52/wz8b.png
https://zupimages.net/up/22/52/xoi8.png

_{Modération : merci d'utiliser des images de petite taille (300x300) ou des miniatures pointant sur ces images.}

Dernière modification par cqfd93 (Le 01/01/2022, à 19:09)

Coeur Noir · Le 01/01/2022, à 20:46

L'utilisateur que tu as créé sous Ubuntu a un nom en toutes lettres ( nom qui est là pour le confort de lecture des humains ) et il a surtout un uid numérique ( qui lui est utilisé par le système comme critère distinctif ).
Le premier utilisateur créé sur un système Debian ou Ubuntu a pour uid 1000 ( et il est de type administrateur sous Ubuntu, c'est l'utilisateur crée à l'installation, il a donc accès aux droits root via la commande sudo ), le deuxième aura pour uid 1001, le troisième 1002, etc. Ces utilisateurs supplémentaires seront au choix de type administrateur ou normal ( = sans accès sudo ).

S'il n'y avait qu'un seul utilisateur sur ta debian/xfce, cet utilisateur avait donc pour uid 1000.
Et du coup l'utilisateur d'uid 1000 sur ton actuelle Ubuntu a légitimement accès aux données appartenant à 1000 ( même si les noms en toutes lettres différent d'un système à l'autre, c'est l'uid numérique le critère distinctif du point de vue du système ).

Les commandes suivantes devraient éclairer :

id			# affiche les identités et groupes de l'utilisateur courant
ls -la /home		# donne les noms d'utilisateurs et groupes sous forme littérale
ls -lna /home		# …sous forme numérique
ls -la /media/$USER	# par comparaison tu retrouveras
ls -lna /media/$USER	# quels noms littéraux ( différents ) relèvent du même propriétaire ( numérique ).
lsblk -fe7,11 -o +size

Pour cette dernière, avant de la lancer, agrandir la fenêtre du terminal car son retour est un tableau assez large ( qui donne les disques et partitions en présence ).

Ensuite Nautilus ne demande jamais le mot de passe admin~root puisqu'il est lancé par l'utilisateur de la session graphique courante.
Si des fichiers ou dossiers n'appartiennent pas à l'utilisateur, Nautilus t'en rendra compte : icône avec croix ou cadenas, message du type « vous n'avez pas les permissions pour… »
On ne lance surtout pas Nautilus via sudo nautilus ( meilleur moyen de corrompre des droits et permissions sur des config's contenues, cachées, dans le rép. perso ).
Si besoin de lancer Nautilus avec les droits de root ( mais pourquoi ? ) il y a un plugin pour Nautilus qui permet de faire ça proprement ( nautilus-admin ) ou à la rigueur la commande pkexec nautilus.

Enfin, en cliquant depuis Nautilus sur sda3 ça l'a monté automatiquement dans /media/$USER/uuid_ou_label_partition ce qui est le comportement normal pour tout ce qui ne se trouve pas déjà « déclaré » dans le fichier /etc/fstab.
En cas de partition contenant un système de fichiers ne gérant pas nativement les droits et permissions Linux/unix, ça l'aurait même automatiquement approprié à l'utilisateur courant ( afin qu'il puisse écrire dedans ) grâce à des ACL. Ce mécanisme est géré par udisksctl qui existe aussi sous Debian.
Ici ta sda3 c'est probablement de l'ext× ( ou autre système de fichiers natif Linux ) donc ça respecte les droits portés par les fichiers contenus dans la partition.

En bref :
⋅ pas de faille de sécurité ici, juste une méconnaissance autour des noms et uid des utilisateurs ( gid pour les groupes ), et des droits et permissions,
⋅ et je m'abstiens de commenter l'emploi du mot inadmissible

Dernière modification par Coeur Noir (Le 01/01/2022, à 21:06)

Nuliel · Le 01/01/2022, à 21:04

Le titre est pas adapté: c'est pas une faille de sécurité, c'est juste parce que l'utilisateur est dans le groupe plugdev

https://wiki.debian.org/SystemGroups a écrit :

plugdev: Allows members to mount (only with the options nodev and nosuid, for security reasons) and umount removable devices through pmount.

Et c'est bien pratique

Si les données sont pas chiffrées, elles sont accessibles depuis un live usb, sans aucune autorisation particulière.
Sinon, oui, avec un dual boot, un Windows, s'il a ce qu'il faut pour lire une partition EXT4 (ce qui n'est pas le cas par défaut) peut lire les données du linux à côté.

Dernière modification par Nuliel (Le 01/01/2022, à 21:07)

Coeur Noir · Le 01/01/2022, à 21:10

On est sur une live-session là ? Ça m'avait échappé, je pensais qu'il s'agissait d'un dual-boot.

Ça répond quoi id depuis une live-session ?

Old tired coder · Le 01/01/2022, à 21:56

Blablabla...

j'ai signalé une faille de sécurité, bien réelle et évidente, avec toutes les explications qui conviennent, après les responsables feront comme ils veulent et moi aussi.

J'ai horreur des passoires : Ubuntu en est une, point trait.

Coeur Noir · Le 01/01/2022, à 22:27

Blablabla… Sérieusement ? On prend la peine de te donner des clés de compréhension et c'est comme ça que tu réponds ?

La passoire ici, c'est pas spécialement Ubuntu… qui n'est jamais qu'une Debian, avec exactement le même fonctionnement point de vue droits et permissions, uid et gid, etc.

Tu as passé les commandes proposées pour repérer les noms et uid ?

Parce que si tu veux on peut factuellement et facilement vérifier les choses.

Si tu ne veux pas de ces vérifications factuelles, tu peux continuer à vivre dans le flou et l'approximation.

j'ai signalé une faille de sécurité, bien réelle et évidente, avec toutes les explications qui conviennent
Ah bon ? Où ? Une opinion n'est pas une vérité ni une évidence.
Par contre le paramétrage et fonctionnement des uid / gid sous Debian, c'est documenté et vérifiable.

Dernière modification par Coeur Noir (Le 01/01/2022, à 22:30)

Old tired coder · Le 01/01/2022, à 22:55

Coeur Noir a écrit :

Blablabla… Sérieusement ? On prend la peine de te donner des clés de compréhension et c'est comme ça que tu réponds ?
La passoire ici, c'est pas spécialement Ubuntu… qui n'est jamais qu'une Debian, avec exactement le même fonctionnement point de vue droits et permissions, uid et gid, etc.
Tu as passé les commandes proposées pour repérer les noms et uid ?
Parce que si tu veux on peut factuellement et facilement vérifier les choses.
Si tu ne veux pas de ces vérifications factuelles, tu peux continuer à vivre dans le flou et l'approximation.
j'ai signalé une faille de sécurité, bien réelle et évidente, avec toutes les explications qui conviennent
Ah bon ? Où ? Une opinion n'est pas une vérité ni une évidence.
Par contre le paramétrage et fonctionnement des uid / gid sous Debian, c'est documenté et vérifiable.

AH! AH! AH! Ubuntu est une Debian ? Mort de rire.

Une opinion, le fait qu'un User peut explorer tous les volumes voisins sans qu'on lui demande de justifier de ses privilèges d'admin ?

Comme disait je ne sais plus quel philosophe : "Quand le sage montre le Ciel, l'imbécile regarde le doigt"

FS · Le 01/01/2022, à 23:13

Bonsoir Coeur Noir,

Personnellement je te remercie pour la peine que tu t'ai donnée afin d'expliquer le fonctionnement des uid , j'ai trouvé ça enrichissant à mon niveau.

Belle soirée FS

Dernière modification par FS (Le 01/01/2022, à 23:14)

Nuliel · Le 01/01/2022, à 23:56

Blablabla...

Tu es sur un forum ubuntu ici, pas debian. Et tu seras gentil de redescendre d'un ton Old tired coder. L'info que j'ai donné vient de la doc debian, et sous debian, c'est pareil (je suis dans le groupe plugdev et sous debian sur mon pc portable sans avoir demandé à être dans ce groupe, et c'est pareil sur mon pc fixe sous ubuntu)
On t'a expliqué factuellement comment on peut monter les partitions sans avoir besoin de rentrer son mdp (le groupe plugdev). Ce n'est pas une faille de sécurité. L'accès aux données est trivial si les données ne sont pas chiffrées. Le chiffrement a pour but de rendre impossible en temps raisonnable l'accès aux données sans la clé de chiffrement.

Dernière modification par Nuliel (Le 01/01/2022, à 23:58)

Coeur Noir · Le 02/01/2022, à 00:06

Et si tu répondais aux questions / donnais les retours des commandes suggérées ?
Système installé ou live-session ?

Et oui Ubuntu est une Debian, ou ce sont tous des menteurs ?
Et oui ça signifie que depuis n'importe quel système, l'utilisateur d'uid tant a potentiellement accès à tout fichier dont le propriétaire porte cette même uid. C'est pas nouveau.

Quant à
Une opinion, le fait qu'un User peut explorer tous les volumes voisins sans qu'on lui demande de justifier de ses privilèges d'admin ?
Encore heureux qu'un User ne soit pas obligé de passer root pour voir les volumes ( périphériques ) attachés à son système, quand il en est un utilisateur légitime !
Ça ne signifie nullement que cet User peut faire tout et n'importe quoi dans les systèmes de fichiers ( données ) hébergés par ces volumes.
Ça dépend de « qui est » cet user ( membre de quels groupes ) et des droits et permissions sur les systèmes de fichiers dans ces volumes.
Les volumes ( périphériques de stockage ) appartiennent à root:disk avec droit brwxr-x--- mais les systèmes de fichiers contenant les données, eux, portent des droits et permissions adaptés en fonction de la nature et destination des données.
Et rien ne t'empêche de changer cela ( côté système de fichiers ) en ajustant les droits et permissions à tes nécessités sur les données te concernant.
Mais la gestion du volume lui-même ( périphérique ) tu la laisses au système, qui inclut par défaut les mécanismes nécessaires pour juger de la légitimité d'un utilisateur à accéder à un périphérique.
Donc pas touche aux droits et permissions dans la racine système, au risque d'empêcher les mécanismes robustes par défaut.

Ou tu pratiques le chiffrement sur des volumes, c'est à la mode. Mais c'est autrement plus contraignant ( et ça n'est que mon opinion suite simplement au nombre d'appels au secours d'utilisateurs n'accédant plus à leurs données chiffrées pour telle ou telle raison ).

Après tu peux choisir l'ignorance mais n'en éclabousse pas les autres.

Dernière modification par Coeur Noir (Le 02/01/2022, à 01:16)

cqfd93 · Le 02/01/2022, à 01:19

Modération

Avec les explications données, on n'a pas besoin d'aller plus loin → on ferme !

Et je change le titre…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 01/01/2022, à 13:02

Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#2 Le 01/01/2022, à 14:32

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#3 Le 01/01/2022, à 15:05

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#4 Le 01/01/2022, à 16:21

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#5 Le 01/01/2022, à 17:21

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#6 Le 01/01/2022, à 18:55

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#7 Le 01/01/2022, à 20:46

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#8 Le 01/01/2022, à 21:04

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#9 Le 01/01/2022, à 21:10

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#10 Le 01/01/2022, à 21:56

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#11 Le 01/01/2022, à 22:27

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#12 Le 01/01/2022, à 22:55

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#13 Le 01/01/2022, à 23:13

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#14 Le 01/01/2022, à 23:56

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#15 Le 02/01/2022, à 00:06

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

#16 Le 02/01/2022, à 01:19

Re : Nautilus : faille de sécurité… QUI N'EN EST PAS UNE

Pied de page des forums