Ce n'est pas une question pour les alternatives (sudo, par exemple) mais sur les raisons techniques et/ou politiques de ce fait.
Concrètement, j'ai regardé rapidement dans le code, et j'ai l'impression que cela se fait par un test direct de l'uid de l'appelant (bout de code copié/collé entre mount et umount, soit dit au passage).
Personnellement, je pense que c'est handicapant, et je ne parviens pas à comprendre l'intérêt de ce fait: après tout, il est impossible d'accéder à /dev/sdXY tant que l'on est pas membre du groupe disk, alors pourquoi ne pas autoriser tout le monde à utiliser la commande mount pour monter?
Puisque de toute façon seuls les membres du groupe disk ont accès à /dev/sdXY, cela ne changerait pas le fait que l'accès au montage serait sécurisé (seuls les utilisateurs appartenant au groupe disk peuvent monter un périphérique), avec en plus le bénéfice pour un utilisateur d'être capable de monter ses iso (chose que l'on peut faire en utilisant fuse, je sais) car étant propriétaire de ses fichiers sans devoir passer par su ou sudo (que je considère comme un workaround, personnellement).
Est-ce à cause d'une raison technique (appel à des fonctions du kernel interdites aux simples mortels? Mais dans ce cas, pourquoi ces fonctions du kernel exigent-elles d'être l'uid 0?) ou purement politique (histoire d'être sûr et certain que seul l'administrateur peut le faire… ah, les privilèges des admins…)?
PS: j'espère avoir choisi la bonne section… ce n'est ni purement une question sur le kernel, ni purement de la prog…
# Sécurité
Posté par ymorin . Évalué à 3.
C'est plus une raison de sécurité.
Si je suis un utilisateur malveillant, je peux insérer une clé USB avec un contenu que je maitrise, et sûrement avec des binaires vérolés (genre, exfiltration de données, keylogger…).
Donc, si je pouvais utiliser
mountsans être root, je pourrais faire, par exemple :Et à partir de ce moment là, tout nouveau process lancé utiliserait mes binaires vérolés. Et donc je serais capable d'obtenir d'exfiltrer des informations de la machine à l'insu du plein gré de ses administrateurs, et surtout de ses utilisateurs.
Hop,
Moi.
[^] # Re: Sécurité
Posté par yohann (site web personnel) . Évalué à 2.
pourquoi pas mais il y a des points qui restent obscure avec cette explication:
pourquoi dans ce cas limiter mount à l'uid 0 au lieu de limiter mount au simple droit d'écriture dans le repertoire de destination:
pour reprendre ton exemple: si un user a le droit d'écrire dans / il n'a pas besoin de "mount /dev/sdX1 /" il peut faire "mv /bin /bin.old && mv ~/rotten_bin /bin" pour un résultat identique.
[^] # Re: Sécurité
Posté par BlueWhisper . Évalué à 2.
Parce que sinon on pourrait mounter un périphérique avec des exécutables Setuid.
[^] # Re: Sécurité
Posté par freem . Évalué à 2.
Je ne connais pas setuid, mais l'article que tu pointes indique que setuid permets de prendre l'uid de l'utilisateur propriétaire du fichier.
Dans ce cas, pourquoi ne pas utiliser un fake user nommé, par exemple, disk (dans la même logique que le groupe affecté aux périphériques de disques s'appelle disk), du coup on ne pourrait plus voler les droits de root via mount?
[^] # Re: Sécurité
Posté par kna . Évalué à 1.
Ça n'empêchera pas que si un user peut monter n'importe quel volume, si le volume contient des exécutables suid root, il pourra les lancer avec les droits root.
[^] # Re: Sécurité
Posté par freem . Évalué à 2.
Autrement dit, dès lors qu'un volume contiens des données, potentiellement exécutables, appartenant a uid=0, quiconque peut le monter (avec ou sans uid=0) peut exécuter les binaires en questions avec les droits uid=0 de la machine qui à monté le matos?
Si c'est le cas, ça crains en effet… Je serai tenté de demander pourquoi dans ce cas ne pas changer les uid des fichiers des volumes externes pour qu'ils ne soient pas uid=0, mais la "réponse" qui me viens à l'esprit est triviale: 1) comment faire la différence entre un périphérique "interne" ou "externe"? (Mais ne serait-il pas possible d'imaginer que ce qui n'est pas dans /etc/fstab est externe, voire d'ajouter une option pour préciser qu'il s'agit d'un périphérique externe? Le souci dans ce cas est qu'il est simple de démonter le disque, de le monter ailleurs et de le manipuler ainsi. Mais du coup, est-ce le rôle de l'OS que de se protéger des manipulations physiques? N''est-ce pas le rôle du BIOS/UEFI plutôt?) 2) comment faire pour avoir un système dont les composants sont situés (pour une raison qui m'échappe) sur plusieurs disques?
J'ai bon? Ou, comme c'est probable, il reste des choses qui m'échappent?
[^] # Re: Sécurité
Posté par khivapia . Évalué à 2.
Pas avec l'option "nosuid" (et "nodev" tant qu'à faire) dans les options de montage dans /etc/fstab
[^] # Re: Sécurité
Posté par kna . Évalué à 2.
Moui, enfin là on parle d'un montage qui n'est pas dans fstab, sinon il y a l'option user aussi
# Je ne comprends pas trop...
Posté par wolowizard . Évalué à 3.
La commande /bin/mount (debian apparemment) peut être utilisée par 'other'.
On peut autoriser un utilisateur de monter un device (epsilon ses droits) par le biais du fstab (options user et users man fstab section 'non super-user mounts')…
Je ne dois pas comprendre la question ou le problème…
[^] # Re: Je ne comprends pas trop...
Posté par freem . Évalué à 2.
Elle peut être utilisée par tout le monde, mais pas avec n'importe quelles options. Par exemple, pour faire
mount /dev/sdc4 /mnt/fooil est nécessaire d'avoir l'uid 0.Effectivement, j'avais oublié le fstab, mais je ne suis pas sûr que cela soit très utilisable dans le cas de périphériques amovibles, ou d'iso.
Si un utilisateur veut utiliser une iso, il lui faut être root, excepté bien sûr, s'il utilise un workaround tel que fuse,
sudoousu.Il n'y à pas vraiment de problème, c'est juste que je me demande pourquoi c'est ainsi, et pas autrement. Comme j'aime comprendre pourquoi les choses font faites ainsi et que je n'ai pas réussi à trouver d'explications réelle sur le sujet, je me suis permis de demander, et je me suis dit que peut-être quelqu'un saurait sur linuxfr ;)
C'est vraiment une question pour comprendre l'architecture du système et les raisons d'un choix qui, à première vue et de mon faible niveau, me paraît étrange, pas une problématique technique (sinon je pourrai juste installer sudo, le configurer n'est pas vraiment complexe).
[^] # Re: Je ne comprends pas trop...
Posté par wolowizard . Évalué à 2.
Ta question initiale c'est "monter/démonter"…
Ensuite suivant l'implémentation il y a différentes options (sur freebsd tu peux monter en étant non root à la condition d'avoir relâché la contrainte d'un sysctl vfs.usermount et epsilon les droits sur le device) comme tu le souhaites…
Sur les utils-linux de ce que j'en ai lu…tu peux monter mais (comme tu le fais remarquer) sans certaines options (tu ne peux pas spécifier la source et la cible).
[^] # Re: Je ne comprends pas trop...
Posté par freem . Évalué à 2.
En fait, je t'avoue que si je pose la question, c'est parce que j'ai lu il y à quelques temps un document qui semble supposer qu'il soit possible sous certains des *BSD de monter sans cette restriction, justement.
Et que je commence à me poser sérieusement la question, au sujet de certaines restrictions du kernel linux. Il n'est par rare de voir des documents relatant des sorties de Linux, rageant contre certains DEs… et problème d'autorisations, qui, il me semblent prennent leurs racine dans le kernel que le sieur Linus est censé superviser justement. Mais troll à part: je suis un néophyte dans ce domaine, et j'ai voulu demander "l'avis du public" qui est régulièrement très très instructif sur linuxfr.
Ma question initiale était aussi probablement mal formulée, le fait que je ne connaisse que kLinux/Debian et Windows(NT<=XP && DOS<W98SE) , et encore (je n'ai jamais été foutu de compiler un kernel qui soit directement fonctionnel, je n'ai donc jamais réussi à installer gentoo. Mais j'ai essayé, à 2… peut-être 3… reprises, ça… hum… prouve mon niveau j'imagine :) ), n'y est sûrement pas étranger.
Je voulais dire, pourquoi ne peut-on pas monter, en tant qu'utilisateur normal, n'importe que device, malgré que l'on soit membre du groupe disk sous Debian, compte tenu du fait que /dev/sd?* appartiennent au groupe disk?
# Pas tout seul
Posté par Obsidian . Évalué à 3.
Ce n'est pas une constante gravée dans le marbre : un simple chgrp/chmod suffit à changer cet état de fait et il faut vérfier cela pour chacun des périphériques spéciaux, un par un.
N'oublie pas qu'UNIX est un système multi-utilisateurs : « mount » ne fait pas simplement qu'accéder au périphérique concerné, il construit également un morceau du système de fichiers entier avec. Un fois une partition montée, elle est visible par tout le système et par tous les utilisateurs, même si sa consultation peut être restreinte par des droits d'accès.
Imagine que quelqu'un ait la bonne idée de faire un mount sur /usr/bin (ce qui est parfaitement légal) par exemple : ceci masquerait la quasi-totalité des binaires du système, qui deviendrait automatiquement inutilisable, à moins d'avoir pensé à garder « umount » sur une partie visible du FS.
[^] # Re: Pas tout seul
Posté par Obsidian . Évalué à 4.
Au fait, j'ai soudain un doute en te relisant : On rappelle que l'utilisateur ayant l'ID 0 est le root, tout simplement.
Dans l'absolu, on pourrait aussi changer le nom de login du root même si c'est une mauvaise idée, mais l'utilisateur ayant l'identifiant nul reste la définition du super-utilisateur, à tous les niveaux du noyau.
Il est utile de rappeler également que — en principe — la philosophie UNIX est « tout est fichier ». Il y a donc d'un côté le super-utilisateur qui a tous les pouvoirs (Dieu sur Terre) et, de l'autre, les utilisateurs ordinaires. Par le biais des bits setuid dans un certaine mesure et surtout des différents droits d'accès, notamment sur les fichiers spéciaux, on peut gérer les privilèges accordés aux différents utilisateurs de façon simple et unifiée, sans que cela fasse l'objet de niveaux prédéterminés comme on en trouvait sous Windows à l'époque (avec les powerusers, admin, etc.).
Ça veut dire que d'une part, tout ce qui peut tourner dans l'espace d'un processus sans avoir la possibilité de perturber ceux des autres utilisateurs peut s'exécuter en mode non privilégié. Autrement, il faudra avoir le droit de le faire.
Ça signifie aussi que « root » n'est pas un utilisateur ordinaire : même l'administrateur d'un site ou celui de sa propre machine ne travaille jamais en root. Il utilise un compte ordinaire auquel il accorde quelques droits pour le travail au quotidien et ne passe root que ponctuellement lorsque c'est nécessaire.
Le bit setuid est également un bon moyen de faire passer automatiquement un processus en root (ou autre identité) tout en limitant ce privilège à l'exécutable de la commande lancée : ça va être le cas de passwd, par exemple, puisque c'est nécessaire pour pouvoir modifier le fichier central lorsque l'on change de mot de passe. C'est également le cas de mount, qui permet à tout un chacun de monter à loisir ce qui se trouve déjà dans /etc/fstab, pourvu que la ligne concernée soit munie de l'attribut "user" ou "users".
[^] # Re: Pas tout seul
Posté par freem . Évalué à 2.
Désolé, mon intention en parlant d'uid0 était d'être plus clair, plus précis quand à ma question.
Je crois que c'est, au contraire, une bonne idée. Après tout, le nom de l'utilisateur est la moitié des informations nécessaires pour accéder un à système.
Bien que je ne changerai pas, de moi-même, le nom de l'uid0 sur une machine qui ne contiens que des informations de faible importance, je pense que je serais fortement tenté de le faire si je sais que la machine en question contiens des informations de haute sécurité.
Après… j'avoue, je n'y connais rien en sécurité, je ne suis pas admin.
Justement, c'est cela qui m'intrigue. Linux est considéré comme un fils spirituel d'UNIX (mais moins que les BSD je crois?) mais on constate une vérification hard-codée dans mount?
C'est justement ce constat, qui m'a fait poser la question. Au final, ces derniers temps, je suis en train de remettre en question dans mon opinion personnelle (j'évite de trop l'afficher, je sais très bien que je ne connais quasiment rien de linux ou même d'UNIX) le fait que LINUX soit si proche d'UNIX que ça, si malléable et adaptable. Je doute.
Et le doute m'entraîne à poser des questions, pour comprendre pourquoi les choses que je crois être des erreurs en sont vraiment.
Tu serais donc encore plus horrifié que moi en voyans la façon de… hum… travailler…. de la boîte pour laquelle je bosse.
Déjà, on demande à des dev d'être admin de serveurs critiques, en plus, on nous demande de déployer des cibles de test sur les serveurs de prod, et, je te le promets à ma grande honte, il n'y à qu'un seul compte sur ces machines: root. J'y suis depuis presque un an, j'ai toujours râlé et gueulé contre cet état de fait (je ne te parle même pas de l'architecture… ou du manque de… des… logiciels… pissés! Et j'abhorre le terme pisser du code, alors si je l'utilise… erk… ceci dit, j'essaie de réduire la cata… utiliser un CVS et un bugtracker, monter un serveur avec des VM pour le test, et je n'ose imaginer faire un buildbot avec tests unitaires, j'ai déjà assez de résistance au changement comme ça!)
Je crois que c'est cette partie là que je ne comprend pas, en fait. Je pense qu'il me faut étudier les effets exacts de ce flag, il n'y à qu'ainsi que je pourrais comprendre pourquoi on teste si le lanceur à l'uid 0 dans mount pour certaines conditions.
Merci de ta réponse en tout cas, c'est très instructif (en tout cas, ça m'amène à me poser de nouvelles questions, ce qui reviens au même selon moi)
[^] # Re: Pas tout seul
Posté par Obsidian . Évalué à 5.
En fait, ça se fait effectivement parfois, mais c'est de la même façon que tu peux remonter /dev ou /proc sur les répertoires de ton choix, et mettre les bibliothèques où tu veux pourvu que tu règles correctement LD_LIBRARY_PATH et ld.so.conf sous Linux. C'est possible mais c'est aller au devant d'ennuis pour rien.
Certes, changer le nom du root te permet éventuellement de te protéger contre les scripts automatiques les plus simples, mais la liste des utilisateurs est visible à travers /etc/passwd, même si c'est en lecture seule. Donc, c'est une protection qui ne sert à rien contre les attaques en local. Contre les attaques à distance, le plus sage est tout simplement d'interdire à root de se connecter directement.
D'autre part, on ne fait pas de sécurité par l'obscurantisme. Si tu as besoin de t'y connecter à distance pour pouvoir faire du dépannage éventuel, le mieux (à mon avis) est d'utiliser un certificat en plus d'une liaison chiffrée et d'un mot de passe fort.
Il y a eu originellement un grand schisme dans le monde UNIX à l'époque où c'était encore le système de quelques grandes compagnies et d'universités prestigieuses, en substance celle de Berkeley. Tu peux visiter SysV sur Wikipédia et la frise d'É. Lévénez qu'on ne présente plus, mais quoi qu'il en soit, deux grandes tendances se sont dessinées : les UNIX basés sur SysV, plus ou moins issu de la lignée originale, et ceux basés sur les travaux de BSD. Il s'est passé en gros la même chose qu'avec Red Hat et Debian dans le monde Linux, ce qui avait donné lieu à une réflexion dans la communauté pour éviter que Linux se scinde lui-même en deux projets.
J'évite d'aller plus loin parce que le fil va se transformer en troll systemd (on est vendredi mais il est encore un peu tôt).
En fait, il y a une raison à cela : si tu écris «
ls -l $(which mount)», tu t'apercevras quemounta le bit setuid. Ça veut donc dire qu'il sera automatiquement lancé en root, même si l'utilisateur ne fait rien de spécial. Ceci lui permet d'offrir la possibilité à l'utilisateur de monter ce qui se trouve déjà dans /etc/fstab, si les lignes concernées possèdent l'attribut « user », ou « users » (le premier impose que ce soit l'utilisateur ayant monté le volume qui le démonte, tandis que le second permet à n'importe qui de le faire). Mais évidemment, lancé en tant que root par un admin ou par un utilisateur ordinaire sous son identité, le programme sera donc root dans les deux cas. C'est donc à lui qu'il appartient de vérifier sous quelle identité il a été réellement lancé pour savoir s'il doit honorer n'importe quelle requête ou s'il doit se cantonner à ce qui est déjà dans /etc/fstab. C'est aussi ce qui va introduire les notions d'identité réelle et d'identité effective (getuid() et geteuid()).Le problème est le même avec la commande « passwd ». Si elle est officiellement lancée en tant que root, elle peut modifier le mot de passe de n'importe qui (utile pour l'administrateur) mais si elle est lancée en tant qu'utilisateur ordinaire, elle ne devra modifier que le mot de passe de cet utilisateur en particulier. Il en reste que, dans les deux cas, le processus doit être privilégié pour modifier le fichier principal des mots de passe.
C'est exactement ce qu'il faut faire, mais attention au biais de conformité.
Si tout le monde a le mot de passe root de la machine, profites-en pour te créer un compte à toi, le mettre dans les sudoers, et travailler normalement même si tous tes collègues utilisent tes serveurs comme des bacs à sable. Au moins sur les machines de développement (les prods ont peut-être un master à respecter mais étant donné la ligne directrice, j'en doute un peu).
Si tu as besoin d'une autre analogie : tu peux comparer ça à l'userland et au mode noyau : tout ce qui est dans le noyau (en ring 0 sur Intel) peut écrire partout et accéder aux ports d'entrées-sorties. Tout ce qui est en user (en ring 3), en revanche, ne peut agir que dans son espace et ne peut acquérir des privilèges qu'en faisant un appel système, qui va le faire entrer dans le noyau et exécuter uniquement ce qui s'y trouve déjà.
« root » est le même principe appliqué aux utilisateurs. Le root est omnipotent et lève par nature toutes les restrictions du système. Tous les autres utilisateurs, eux, sont les mêmes a priori. Comme, sous Unix, tout est censé être fichier, on est théoriquement en mesure de donner des droits d'accès à n'importe quoi. C'est aussi pour cela que ça devient pénible quand certains projets (notamment des environnements de bureau) s'éloignent de ce principe pour réinventer ensuite leurs propres méthodes de contrôle.
Le principal danger à travailler sous root ne vient pas des attaques potentielles de l'extérieur : ça lève tous les garde-fous légitimement mis en place. Par exemple, quand on formate une partition et que l'on monte un volume sous Unix, le système a le bon goût de réserver cinq pourcents (par défaut) de cet espace et de le considérer comme plein quand un utilisateur atteint cette limite. Si c'est la partition système qui est concernée (probable s'il n'y en a qu'une seule sur le disque), ça empêche ton système de démarrer correctement, comme partout. Mais le fait d'avoir cette réserve te permet justement de te connecter en root (en mode dégradé ou mono-utilisateur), de faire le ménage et de relancer le système proprement. Si tu travailles tout le temps en root, tu blindes ta partition et le seul moyen de s'en sortir est d'utiliser un LiveCD pour aller le réparer depuis l'extérieur. Et ceci n'est qu'un exemple. Voir également ce journal et les commentaires qu'il a suscité : http://linuxfr.org/users/faya/journaux/contre-la-phobie-du-root
Aujourd'hui, tu as le droit d'utiliser git ou mercurial. CVS est vénérable et le plus répandu parce que le plus ancien (probablement). Il a inspiré tous les suivants mais désormais, il a le droit à une retraite bien méritée. Je n'aime pas beaucoup le changement non plus mais essayer l'un ou l'autre pendant un après-midi suffit à être convaincu et à ne plus revenir en arrière.
« ls -l » permet de voir instantanément les neufs bits des droits d'accès habituels des fichiers : « rwxrwxrwx », soit les droits en lecture, écriture et exécution (ou parcours s'il s'agit d'un répertoire) pour, respectivement, le propriétaire du fichier, les membres du groupe auquel appartient ce fichier, et tous les autres.
Mais il en existe trois autres : setuid, setgid, et le sticky bit. Les deux premiers sont nommés ainsi relativement à la fonction qu'ils semblent appeler. Concrètement, si un utilisateur quel qu'il soit a le droit d'exécuter le fichier (binaire exécutable) et le fait, alors si le bit setuid est posé, le programme sera lancé avec l'UID du propriétaire du fichier et pas celui de la personne qui l'a lancé. Même chose avec setgid() : le processus appartiendra au groupe dans lequel est placé le fichier. Il est important de noter que ce propriétaire (et donc l'UID effective du processus) n'est pas forcément root, mais c'est utilisé à cette fin dans neuf cas sur dix.
Le sticky bit, lui, quand il est placé sur un répertoire, sert à permettre aux utilisateurs de modifier un fichier qui n'est pas le leur si ils en le droit (« w ») mais leur interdire de le supprimer, réservant ce droit au propriétaire du fichier ou du répertoire qui le contient.
# Pour des raisons évidentes
Posté par millman . Évalué à 4.
Si un utilisateur à la capacité d'utiliser la commande mount il peut aussi utiliser l'option remount et changer les options de montage en enlevant par exemple un nosuid ou un nodev ou changer l'utilisateur d'une partition NTFS…
Il peut aussi par exemple récupérer et monter une image squashfs contenant un programme appartenant à root et possédant le setuid.
On peut trouver plein d'autres exemples.
Sinon en faite il n'est pas nécessaire d'avoir l'uid 0 pour avoir le droit de faire l'appel système mount. Il faut avoir la capability CAP_SYS_ADMIN (les processus ayant l'uid 0 sont des processus privilégiés possédant toutes les capabilities par défaut).
[^] # Re: Pour des raisons évidentes
Posté par freem . Évalué à 2.
D'un autre côté, seul l'utilisateur uid=0 peut distribuer les groupes, donc si un user fait partie du groupe disk, c'est parce que uid0 l'a décidé ainsi non?
Par contre, comme je l'ai dit plus haut, je ne connais pas le bit setuid, et il semble que ce soit une bonne source d'explication, il me faut donc aller lire quelques manuels pour comprendre de quoi il retourne exactement, ainsi je pourrais peut-être comprendre cette restriction qui me semble si arbitraire.
C'est intéressant. Comment root pourrait-il donne cette capacité à un autre utilisateur, ou groupe? Est-ce possible sous linux?
Cette répones est ce qui semble s'approcher le plus d'une solution qui ne fasse pas figure de workaround au problème du montage de périphs. Ce qui n'enlève rien à la pertinence des autres réponses, bien sûr, mais si je le pouvais, je te plussoierais 2 fois.
[^] # Re: Pour des raisons évidentes
Posté par fearan . Évalué à 2.
le bit de setuid (chmod +s plop) donne a l'executeur du programme l'uid de propriétaire du programme; par exemple
chmod +s /bin/rm, permet à n'importe qui d'effacer des ficher;
chmod +s /bin/vi, permet à n'importe qui de lire et d'écrire n'importe quel fichier (don les /etc/shadow et /etc/passwd pour aller rajouter un utilisateur deus, sans mot de passe, et avec un uid 0)
Monter une partition avec des binaires (comme bash) ayant un tel bit et un trou béant dans la sécurité; alors tu peux arguer aujourd'hui qu'on pourrait limiter le options de montage pour les utilisateur non root (nosuid obligatoire ), interdire le remount…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pour des raisons évidentes
Posté par freem . Évalué à 2.
J'ai surtout envie d'arguer que j'ai bien fait de poser la question, j'ai appris pas mal de choses de vos réponses :)
# sécurité
Posté par alicerr . Évalué à -3.
Parce que Linux a besoin d'aide de l'uid 0,ainsi il fonctionne bien.
[^] # Re: sécurité
Posté par freem . Évalué à 2.
Désolé, mais quand on me répond "parce que", je t'avoue que j'ai une envie folle d'envoyer paître le pâtre.
# Commentaire supprimé
Posté par alicerr . Évalué à 1. Dernière modification le 12 janvier 2015 à 09:07.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.