Bonjour Nal.
Longtemps que je ne t'avais pas écrit. Et tu me connais j'aime bien les titres provocateurs, donc forcément. Donc chers lecteurs, avant de se lancer dans le troll de haute voltige, laissez-moi vous narrer une petite anecdote qui m'est arrivée aujourd'hui.
Plantons le décors.
Je bosse pour une petite société de service tout ce qu'il y a de sympa. Vraiment. On est une vingtaine de techniciens et ingés dont les compétences sont bien évidemment vendues à de plus grosses boîtes.
Votre serviteur est donc en sous-traitance chez un gros gros industriel par chez moi. Quand je dis gros industriel, cela devrait vous mettre la puce à l'oreille sur la dette technique qu'on peut se trimballer. Certains projets ayant des durées de vie se comptant littéralement en dizaine d'années avec des contraintes très fortes sur le fait de devoir maintenir en fonctionnement des archis antédiluviennes (j'ai des Solaris 2.6 en production encore, c'est vous dire).
Vous imaginez bien le conservatisme des gens du cru (pas plus tard qu'hier, j'ai dû intervenir sur une CentOS 7 récemment installée, pas par mon équipe, où le client faisait tranquillou des mknode dans le /etc/rc.local…..)
D'un autre côté, on ne peut pas non plus rester indéfiniment sur des archis trop vieilles, et donc certains des chefs informatiques des services avec lesquels on bosse sont plutôt à jour. Certains ont même monté leur petite infra avec du Ansible et tout et tout. Donc on n'est pas complètement non plus à la ramasse, faut être honnête, même si les techniques « modernes » ne sont pas encore la majorité chez nous..
Bon, c'est bien beau tout ça, mais c'est quoi ces histoires de Ubuntu là ? J'y viens j'y viens.
Soit une architecture qui devra être dans un endroit nécessitant une hardening particulier des machines. Jusque là, tout va bien. L'archi est constituée de machines tournant sous Solaris et sous RHEL / CentOS. On nous demande de faire des tas de choses dessus pour se mettre en conformité avec la politique de sécu qui s'applique à cette archi. Jusque là, tout va bien. On s'en occupe, on blinde le /etc/sudoers, pam, sshd et tout le toutim, on se retrouve face à des comportements chelous de Solaris mais on est forts, beaux et on a le poil luisant, donc on y arrive.
Mais… Bah oui, tu te doutes qu'il y a un mais cher Nal.
Voilà-t-y pas qu'un des chefs chez le client (qui se trouve être responsable de cette archi, œuf de course) qui passe son temps à nous dire que CentOS /RHEL ça pue, que Ubuntu c'est le bien et donc vient nous dire qu'il faudrait qu'on supprime le mot de passe root et qu'on locke le compte (parce que ça le gonfle de devoir générer un mdp root qui sera mis en enveloppe scellée sous séquestre)
Vous imaginez bien, chers lecteurs, qu'en tant que vieil admin poilu et nazi, mon sang ne fait qu'un tour et ma première réponse oscille entre :
- non
- fuck off
- tu te foutrais pas un peu de ma gueule là ?
- et sinon, tu veux m'apprendre mon taff aussi ?
- mais va crever la gueule ouverte sale adorateur de la pire distro jamais faite
Bon. Vous vous doutez bien que je ne peux pas me permettre de répondre ça tout de go à mon client adoré.
Il est pour moi évident qu'il est hors de question de ne pas mettre de mot de passe root sur une machine. Mais là commencent à arriver plusieurs interrogations.
La première d'entre elle étant : Comment justifier notre refus de faire cela ?
Après rapide brainstorming avec l'équipe, on a deux arguments pour refuser.
Le premier étant pour nous suffisant. Et si jamais on a besoin de passer en mode single user parce que la machine est complètement aux fraises et à deux doigts de nous claquer entre les mains ? Je suis loin d'être sûr que chez Sun (oui, Sun, pas Oracle) ils aient prévu ce cas là.
Deuxième argument : on a regardé les docs de l'ANSSI, on a regardé les docs de sécurisation des grandes distros (debian, RHEL, Suse, Gentoo, même Arch c'est vous dire) et dans aucune de ces docs il n'est préconisé de ne pas mettre de mot de passe à root et d'entièrement locker le compte root (certains gens chez le client ayant même parfois demandé à… Virer root de /etc/passwd … facepalm …)
Ce truc de compte root sans mot de passe vient directement de cette engeance de Satan qu'est Ubuntu. J'en ai des frissons et des envies de me désinfecter les mains au papier de verre rien que d'écrire Ubuntu. Berk.
Bon. Maintenant, je me dis… Parce qu'il faut quand même savoir se remettre en question, et si pour le coup, Ubuntu avait raison (bon sang, je n'en reviens pas d'écrire ça) ? Mais sachant que cette distro est faite avant tout pour les tanches qui ne connaissent que Windows en mode God sur la machine, qui font n'importe quoi en admin, est-ce vraiment une friture de sécurité qui vaut le coup ?
Moi, je suis persuadé que non. Mes collègues dans l'équipe sont du même avis que moi.
Mais vous chers lecteurs ? Auriez-vous des réflexions autour de ça ?
D'autres arguments allant dans mon sens de nazi qui conchie les X-buntu ?
Ou bien des arguments allant dans le sens des choix réalisés par Ubuntu qui est à ma connaissance la seule distro où root n'a pas de mot de passe par défaut.
# Compte d'urgence
Posté par Dafyd . Évalué à 10.
Hello
Chez nous sur les environnements de ce type on désactive le compte root, par contre on créé un utilisateur d'urgence, qui est dans les sudoers, avec un mot de passe ET un identifiant généré aléatoirement et mis sous enveloppe. Comme ça, si quelqu'un veut bruteforcer le compte, il lui faudra trouver le mot de passe mais aussi le login. Root c'est trop facile, tu es sur de le trouver sur tous les UNIX.
Un bon compromis ?
[^] # Re: Compte d'urgence
Posté par Fopossum . Évalué à 6.
Et en cas de passage en single user, on fait comment ?
C'est une vraie question. Le matos n'est pas récent avec des risques forts de commencer à déconner et où seul le single user peut être disponible. Donc locker root… Ça me paraît… Un tantinet joueur.
cd /pub && more beer
[^] # Re: Compte d'urgence
Posté par Dafyd . Évalué à 6.
init=/bin/sh sur la ligne d'arguments du kernel dans Grub dans ce cas…
[^] # Re: Compte d'urgence
Posté par Fopossum . Évalué à 10.
Solaris sur du SPARC et grub c'est juste pas possible ;-)
Ainsi que stipulé par la doc de Solaris 11 le passage en single demande le mot de passe root.
Donc… Je maintiens que je suis loin d'être sûr que de ne pas mettre de mdp pour root ce soit une chose à faire.
Oui, je suis un vieux con qui bosse sur des OS qui datent de y'a longtemps, mais… Pas le choix là.
cd /pub && more beer
[^] # Re: Compte d'urgence
Posté par groumly . Évalué à 5. Dernière modification le 04 mars 2021 à 23:17.
Disons que l’approche est déconcertante, surtout après avoir sorti « va crever la gueule ouverte ».
Soit y’a une raison très claire qui te fait dire ça, et t’as pas besoin d’aide, soit t’as une intuition que c’est une très mauvaise idée, et tu demandes conseil.
Mais vu les tournures de phrases, tu donnes l’impression d’avoir atteint une conclusion avant de considérer le problème, et part a la cueillette d’argument pour justifier une réaction épidermique. Ça donne une impression de biais de confirmation.
Édit: et merde, j’ai pas répondu au bon thread.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Compte d'urgence
Posté par fearan . Évalué à 7.
Bloquer le remote connect du root ne suffit pas ? Si quelqu'un a un accès à la machine il ne va pas remarquer un identifiant ne correspondant à rien ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Pourquoi ne pas le faire ?
Posté par flan (site web personnel) . Évalué à 10.
J'ai du mal à comprendre le principe de « je ne sais pas pourquoi je ne veux pas le faire, donc donnez-moi des idées ».
Soit il y a un vrai besoin de pouvoir se connecter en root directement (et qu'il n'y a pas moyen de faire autrement) et dans ce cas cet argument est suffisant pour refuser de verrouiller ce pauvre compte innocent, soit il n'y a pas d'argument solide pour refuser, et dans ce cas, pourquoi ne pas le faire au lieu de chercher désespérément des arguments ?
[^] # Re: Pourquoi ne pas le faire ?
Posté par Fopossum . Évalué à 10.
Je sais pourquoi je ne veux pas le faire. Le risque de ne pas pouvoir intervenir en single user. Si tu as déjà été confronté à un Solaris qui part en sucette, tu devrais voir l'intérêt du single user :-)
Mais il se peut que je sois dans le faux, complètement, donc je demande à d'autres :-) Puis si ça se trouve je finirai par être convaincu si des arguments me sont apportés
cd /pub && more beer
[^] # Re: Pourquoi ne pas le faire ?
Posté par Colin Pitrat (site web personnel) . Évalué à 9. Dernière modification le 04 mars 2021 à 09:16.
Ce passage du journal (entre autres) :
laisse penser qu'il y a un sacré biais méthodologique.
Je pense que le mieux serait de documenter les plus et moins de chaque solution (avec l'aide de ceux qui défendent chaque solution) et aussi de voir si il y'a des solutions alternatives. De toute évidence tu peux trouver des raisons de ne pas changer. Tu peux aussi trouver des raisons de changer (tu en a cité une et elle n'est pas forcément débile). Ce qui compte au final c'est la balance de ces bénéfices et inconvénients pour vous. Au final, le document devrait indiquer quel choix est fait (ou recommandé) et pourquoi (quel argument tranche).
Note: en général il devrait y'avoir une ou deux raisons qui permettent de trancher. Si c'est toute une liste, ca sent le mille-feuille argumentatif. Si la moitié des arguments étaient transférés à l'autre solution, laquelle gagnerait ?
Re-note: ça veut peut-être dire tester le setup en question pour voir ce qui se passe dans le cas ou la machine est tanquée. Oui ça peut être beaucoup de travail pour une décision qui te saoule :)
[^] # Re: Pourquoi ne pas le faire ?
Posté par YBoy360 (site web personnel) . Évalué à 9.
Moi j'aime beaucoup sa démarche. Et je me pose la même question concernant sudo et le mot de passe root…
En plus j'ai travaillé 6 ans chez Sun, pour migrer des très gros (très très gros) logiciels de Solaris 2.6 à Solaris 10, SunStudio, certifier les plateformes, faire de l'optimisation CPU/GPU, corriger les Heisenbugs des compilateurs, me faire taper dessus jusqu'à plus soif…
C'était génial, mes clients c'était Airbus, Boeing, Volkswagen, Renault, Ford. Puis Billou est arrivé avec son chéquier, et d'autres erreurs de management de Sun et je me suis cassé.
Bref, ce journal m'évoque plein de choses à conter, comme l'auteur, je déteste Ubuntu pour plein de vrais raisons… Que d'émotion!
# init=/bin/bash
Posté par Gilles Mocellin . Évalué à 10.
Dans tous les cas, à l’extrême tu dois pouvoir toujours prendre la main su un Linux en passant le paramètre suivant au kernel :
init=/bin/bash
Donc le mode single user, ça fait bien 10, non 20 ans que je n'ai pas utilisé…
[^] # Re: init=/bin/bash
Posté par Christie Poutrelle (site web personnel) . Évalué à 4.
Ça marche vraiment ça ?! Si oui c'est assez ouf, je n'y ai jamais pensé. Et ça monte quand même ton rootfs au minimum et tout ce qui va bien ?
[^] # Re: init=/bin/bash
Posté par jtremesay (site web personnel) . Évalué à 5.
Oui, ça marche. Quand le kernel passe la main à init, le rootfs est déjà monté (généralement en read-only, cela dépend de ce que tu as configuré dans le bootloader).
[^] # Re: init=/bin/bash
Posté par Fopossum . Évalué à 4.
Voui, mais…. Solaris. Ce vieil UNIX que plus personne n'utilise.
Je me permets de me citer :
cd /pub && more beer
[^] # Re: init=/bin/bash
Posté par jtremesay (site web personnel) . Évalué à 7.
Je ne connais pas Solaris. Mais quelque soit le système, je serai assez surpris que le rootfs ne soit pas monté au moment de lancer init. Je veux dire, si
/n'est pas dispo, comment exécuter/bin/init(ou autre) ? Et comment ce dernier pourrait accéder à/etc/fstabpour savoir comment monter/?[^] # Re: init=/bin/bash
Posté par Fopossum . Évalué à 1.
Alors sous Solaris, passer un /bin/bash au boot risque de tout péter parce que c'est du sh pur et dur déjà (bon, ça dépend un peu des versions mais en gros c'est ça)
Le truc, c'est que je suis loin d'être sûr de me retrouver avec un shell si je n'ai pas de mpd root en fait. Et j'avoue que j'ai pas trop envie de tester ce comportement sur les machines. On n'a pas franchement de machines de pré-prod. Souvent, trop souvent, la machine de « pré-prod » devient la machine de prod. Ahem…. J'ai mal mais parfois pas le choix.
cd /pub && more beer
[^] # Re: init=/bin/bash
Posté par Dafyd . Évalué à 7.
Si tu veux faire des tests sous de vieux Solaris, le mieux c'est d'utiliser les zones Solaris 8 que propose Solaris 10, lui même virtualisable en LDOM sur un S7-2 en Solaris 11.
Après de toute manière même sous Solaris, si tu boot en single tu n'as que 2 comportements possibles. Soit tu as direct un shell root, soit tu as un prompt de login, te permettant d'utiliser un autre compte que root.
Le fait d'avoir root désactivé ou sans mot de passe n'empêche pas d'avoir un shell root. Pour preuve, désactive root, ne lui met pas de mot de passe, et depuis un autre user tapes sudo sh.
[^] # Re: init=/bin/bash
Posté par Fopossum . Évalué à 2.
D'après la doc non. Le système demande le mdp root
Donc on en revient à la question initiale. Quel est l'intérêt de désactiver le compte root.
Parce que oui, le client veut qu'on fasse un passwd -l sur root. Et qu'on ne mette pas de mdp à root.
C'est quoi le but ? L'utilité ? Le sens même de cette chose ?
cd /pub && more beer
[^] # Re: init=/bin/bash
Posté par Dafyd . Évalué à 3.
Mea culpa ! Et il se passe quoi quand tu fais le Ctrl-D to bypass ?
L'intérêt de ne pas mettre de password a root est de ne pas pouvoir se loger avec. Cela est utile pour empêcher toute action d'administration non nominative, ainsi que pour réduire la surface d'attaque de la machine, root étant le seul utilisateur que tu trouves partout et donc que les bruteforcer tentent.
Il est des cas, assez spécifiques je te l'accorde, ou la traçabilité des activités d'administration est tellement importante qu'on préfère jeter la machine et en faire une autre que de se loger root dessus.
Après, peut-être peux-tu simplement expliquer le risque que cette mesure de sécurité lève, et au client de l'assumer, ou non…
[^] # Re: init=/bin/bash
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
On peut avoir un compte non appelé root avec un uid 0, et il aura tous les droits de root. Mais je crains que des programmes dans l'espace utilisateur fassent des choses type
chmod root, ou que le démarrage mono-utilisateur se passe mal.[^] # Re: init=/bin/bash
Posté par fearan . Évalué à 4.
on peut même avoir plusieurs compte avec uid 0 sous linux (sous solaris faut voir), tu peux donc avoir le compte root disabled et un autre deus par exemple, celui qui est affiché dans les ls -l est le premier dans le passwd; mais je n'ai aucune idée de comment ça marche pour les mode single user; je crains que cela ne règle pas le problème…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: init=/bin/bash
Posté par lockidor . Évalué à 5.
Oui, c'est pour ça qu'il faut chiffrer les disques si l'on craint une attaque physique :)
# Fedora
Posté par ff9097 . Évalué à 7. Dernière modification le 03 mars 2021 à 20:13.
De mémoire il n'y a pas non plus de mot de passe root par défaut sur Fedora. Pas de quoi en faire un drame cela dit…
[^] # Re: Fedora
Posté par Philip Marlowe . Évalué à 4.
Il n'y en a plus, ça date de quelques versions. Pour se voir proposer de créer le compte root à l'installation, il faut partir de l'install de Fedora server, qui propose comme option la version station de travail.
[^] # Re: Fedora
Posté par Fopossum . Évalué à 2.
Euh…. J'écris depuis une Fedora 33 avec un compte root défini à l'install, en mode KDE Spin. Et c'était une 29 à la base. (Avant j'étais sous Gentoo mais j'en ai eu marre de passer des heures à compiler)
Donc, qu'on puisse ne pas en mettre un OK, mais Fedo propose toujours de mettre un mdp à root à l'installation. Contrairement à Ubuntu qui ne semble pas proposer cette possibilité.
cd /pub && more beer
[^] # Re: Fedora
Posté par mrintrepide . Évalué à 4.
Depuis Fedora 32, je crois, avec l'ISO Workstation (donc GNOME), la création du compte utilisateur est fait au premier démarrage et non à l'installation. Il ne demande pas non plus de mot de passe pour root.
Il faut passer par l'ISO Fedora Everything pour avoir l'option.
[^] # Re: Fedora
Posté par Fopossum . Évalué à 2.
Du coup, question qui vient. Est-ce la mort de « root » ?
Et corollaire, est-ce l'influence de Gnome ou d'Ubuntu pour amener à ce comportement ?
Ou suis-je en train de complètement passer à côté d'un changement de paradigme influencé aussi par Android et tout ce qui est conteneurs ?
cd /pub && more beer
[^] # Re: Fedora
Posté par redo_fr . Évalué à 7.
Il faut bien comprendre que 'root', c'est pas un compte, c'est un état :-)
par défaut, la machine démarre en 'root', puis applique une surcouche de sécurité avec les comptes utilisateurs. Elle fait la même chose avec tout programme lancé : D'abord en "root" puis diminution des droits par changement de compte. Donc non, 'root' par définition ne peux pas "mourir". par contre, éviter d'utiliser le compte 'root' (par définition intraçable) qui en quelque sorte "supprime" la sécurité des comptes, pour éviter les "oups, j'ai effacé le fichier…", c'est à mon avis une amélioration.
Ce n'est pas l'influence d'Android, juste que les systèmes en général deviennent tellement complexes qu'il est plus facile de faire une bêtise (et plus grave) qu'avant avec les droits 'root' et "qu'on" préfère savoir qui fait quoi sur les machines. C'est plus facile de tracer un "sudo" qu'un "su -" (et le/la premie(è)re qui me sort "sudo su" je le(la) crucifie :-P
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Fedora
Posté par Fopossum . Évalué à 1.
Bah… je sais pas, auditd permet de tracer non ? Ou alors j'ai mal compris l'utilité du bouzin.
Je vais passer pour un intégriste mais non, le système n'est pas complexe. Les trucs en plus qu'on rajoute, peut-être, mais le système, ça reste le système. un shell, des commandes pour interagir avec le système, un kernel pour coordonner tout ça et c'est bon.
Bah si. sudo su - root a son interêt.
Si je suis en mode parano, je vais pas laisser sudo garder le mdp pendant bcp de temps. Je fais un sudo « commande à la con qui demande d'être root et qui sort une palette de trucs à lire pour comprendre d'où vient le souci ». Je sais quelles actions faire pour corriger le problème. Et souvent, c'est pas juste passer une commande. Et je dois retaper mon mdp user (minimum 12 caractères, chiffres, lettres, majuscules, minuscules, caractères spéciaux, changé tous les 90 jours et j'ai pas le droit d'avoir mon keepass sous la main parce que le système est en zone ultra sécurisé tout ça) pour chaque commande…
Non, c'est pas vivable. donc…
sudo su - rootFTW.cd /pub && more beer
[^] # Re: Fedora
Posté par freem . Évalué à 5.
Utiliser
sudo -ifait le job aussi, non?[^] # Re: Fedora
Posté par Philip Marlowe . Évalué à 2.
Avant 32. J'ai installé des Fedora pour mes enfants c'était à partir de la 28 ou de la 29, de mémoire.
[^] # si, si, pass root
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je ne sais pas quand ça a changé, mais il me semble que Ubuntu (et certaines versions/variantes de Debian) ont bien un mot de passe root, mais généré aléatoirement (donc pas demandé à l'installation) et le premier compte créé (toujours à l'installation) a tous les droits via sudo (dont le paquet est donc systématiquement installé.) C'est bien parce-que ça répond aux recommandations d'avoir un mdp unique et random par machine.
De même, sur la plupart des distributions, la configuration par défaut du démon openssh interdit la connexion en root avec mot de passe (par contre c'est OK avec des clés autorisées.) Mais on laisse cette connexion en console (à ce niveau, si brute force, ce sera une attaque par des personnes en interne.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Mode maintenance...
Posté par redo_fr . Évalué à 10.
Tu peux "locker" autant que tu veux ton compte 'root', si tu passes en mode "maintenance" sur ubuntu (équivalent du "single user")… he beh t'es "root" :-)
J'ai un parc de plus de 300 stations et serveurs sur Ubuntu, aucun n'a de compte 'root' avec mdp. Pourtant en cas de soucis, la machine peut se mettre d'elle-même en mode maintenance (ou je peux l'y forcer) et j'accède à un shell 'root' si nécessaire.
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Mode maintenance...
Posté par Fopossum . Évalué à 2.
Ok…. Paye ta sécu.
Root direct. Ahem…… Sans mdp ? Je sais pas, moi ça me file de l'urticaire direct.
Suis p'tet déjà un vieux con en fait.
cd /pub && more beer
[^] # Re: Mode maintenance...
Posté par jtremesay (site web personnel) . Évalué à 2. Dernière modification le 03 mars 2021 à 21:36.
Ça dépend des distribs. Ubuntu demande le mot de passe, alors qu'à priori RHEL non.
Et après y'a des gens pour essayer de nous faire croire que RHEL c'est mieux qu'ubuntu :rolleye:
(Ok, Ubuntu le demanderai SI il était configuré)
[^] # Re: Mode maintenance...
Posté par redo_fr . Évalué à 4.
non, il y a un user/mot de passe dans grub, tu ne peux pas ouvrir le mode maintenance sans authentification :-)
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Mode maintenance...
Posté par xcomcmdr . Évalué à 4.
J'ai toujours utilisé Ubuntu (bon en fait pendant longtemps j'ai aussi utilisé Arch mais chut) et ça a toujours demandé le mdp.
Tu bluffes, Martoni !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# wheel
Posté par _kaos_ . Évalué à 10.
Salut,
Renomme
rootenwheel, ça passera crème :pMatricule 23415
[^] # Re: wheel
Posté par Fopossum . Évalué à 1.
Ne me tentes pas :-P
cd /pub && more beer
[^] # Re: wheel
Posté par _kaos_ . Évalué à 5.
Salut,
Peut-être aurais-je du dire ça passera iScream au près du N+pressé :p
Matricule 23415
# root en SSH via certificats
Posté par madhatter (site web personnel) . Évalué à 10.
Salut,
je vais peut-être passer pour un taré, mais sur l'infra que je gère dans la collectivité dans laquelle je bosse, je n'ai QUE le compte root sur les VM.
Les mdp sont générés aléatoirement au déploiement et déposés dans un coffre fort numérique (type Keepass).
L'accès root en SSH n'est autorisé que via clé publique et interdit par mot de passe et nous utilisons des certificats SSH (des clés publiques signées par une autorité).
J'ai donc la traçabilité de qui se connecte à quoi et quand via les uuid des certificats et je gère qui a accès à quoi en déployant une liste des noms d'utilisateurs autorisés à se connecter via certificat sur les machines (les noms d'utilisateurs sont inclus dans les certificats).
Pour des besoins particuliers, j'ai aussi créé ponctuellement d'autres "autorités" (ou paires de clés permettant de générer les certificats) et n'ai déployé la clé publique de ces autorités que sur certains groupes de machines pour distinguer des accès "presta" des accès admins internes au service… (et ainsi me permettre de ne pas signer les clés des prestas avec la même autorité qui signe les clés de mes collègues et la mienne).
J'ai eu beau réfléchir à cette archi un moment, elle n'est probablement pas parfaite. Je suis donc ouvert à la critique et aux suggestions et toujours en quête d'améliorer la sécurité du bouzin, alors n'hésitez pas. ;)
There is no spoon...
[^] # Re: root en SSH via certificats
Posté par Papey . Évalué à 2.
Je ne suis pas expert mais du coup, si tous les logiciels tournent sous root, la moindre faille de sécurité permettant de lancer un shell le fait en root et donne accès à toute la machine, ce qui permet d'installer des logiciels non désirés dans les couches basses des VM sans avoir besoin de faire une escalade de privilèges. Ceci facilite grandement le travail des attaquants, non ?
[^] # Re: root en SSH via certificats
Posté par madhatter (site web personnel) . Évalué à 2.
Non, je me suis mal exprimé : quand je dis que je n'ai que le compte le root, je veux dire que je n'ai pas de compte utilisateur (uid >= 1000). Mais j'ai bien des comptes systèmes pour les applis afin qu'elles ne fonctionnent pas avec les droits de root.
Mais ce n'est pas forcément le cas pour toutes les applis sur toutes les VM. Il y aurait un peu de travail à faire de ce côté là. ^
There is no spoon...
# Pas de quoi en faire un plat + une question
Posté par cg . Évalué à 4.
Pour le boot en mode crash, il y a le
init=/bin/shdéjà mentionné (est-ce que ça fonctionne sur Solaris ?), mais aussi le démarrage sur le réseau, sur USB (ou floppy 5'¼ avec tomsrtbt dans ton cas ;) ). Bref, ça ne me semble pas un argument très fort.Ce que j'ai plus de mal à comprendre, c'est le sens de "désactiver le root". Plein de processus tournent en user root/0. Certes, tu peux enlever le sticky de /bin/su ou blinder pam (puis faire un sudo su à la place), mais comme ça pour moi la phrase n'a pas de sens :-/ . Y'à un truc que j'ai pas compris ?
[^] # Re: Pas de quoi en faire un plat + une question
Posté par Fopossum . Évalué à 2.
Non….
« Prompt ok » puis boot -s où le système demande… Le mdp root.
Impossible. Pas de serveur jumpstart disponible. Serveur critique hors du réseau (pour simplifier)
Non plus. Interdiction d'avoir un périphérique de stockage de masse pour intervenir ou alors faut avoir l'aval de la sécu toussa toussa et c'est… Long.
Pas de mdp pour root et derrière un passwd -l pour locker le compte.
cd /pub && more beer
[^] # Re: Pas de quoi en faire un plat + une question
Posté par cg . Évalué à 0.
Ah oui, dans ce cas-là tu as des règles et des ordres contradictoires. Dans ce contexte, ça semble en effet risqué de ne pas pouvoir passer root en mode dégradé. Dans un autre contexte, c'est à réfléchir…
Bon courage !
# troll
Posté par Psychofox (Mastodon) . Évalué à 8.
Chez nous on a une majorité d'ubuntu et elles ont toutes un mdp root.
Cela-dit au final un mdp root ça ne sert pas à grand chose. Si une machine est aux fraises et finit en single user mode, une image live sert tout aussi bien. Et au final t'as plus vite fais de la réinstaller. Via foreman une machine a un OS tout frais en 5 minutes. Avec puppet, 5 minutes plus tard au pire la conf de ta machine est restaurée. Les données? Si elle en héberge et que c'était un noeud simple, ben c'est que t'as un SLA bien large donc t'as le temps de restaurer pépère, tout le monde s'en branle de cette appli. Si c'est un noeud d'une archi haute dispo, ben tu relances la synchro et personne n'a rien vu.
[^] # Re: troll
Posté par Fopossum . Évalué à 3.
Hum….
Zone sécurisée. Limite hors réseau tout ça.
Et… Foreman sait reinstaller du Solaris SPARC ? Je veux bien, si c'est le cas. Mais… J'ai un doute.
Euh…. Tu entends quoi par simple là ?
2h de SLA.
Donc reinstallation d'un système Sun. 20 minutes juste pour le premier boot. Installation du système sans puppet / foreman / ansible / truc.
1h30 plus tard, j'ai mon système up. Au mieux.
Maintenant, pour les donnés et la conf… En comptant la reinstallation de Netbackup parce que le client n'a pas considéré que l'option bare-metal recovery était utile, quelques heures de plus.
Alors ouais mais….
Je crois avoir mentionné dans mon journal les choses suivantes : dette technique lourde et méthodes d'un autre temps sauf rares entités un peu plus « à la pointe »
cd /pub && more beer
[^] # Re: troll
Posté par Psychofox (Mastodon) . Évalué à 8.
Ben tu l'as ton argument contre l'abandon du mdp root. Tu leurs dis que ta boite travaille avec des méthodes d'il y a 25ans, et des OS dépassés et que s'ils veulent améliorer quelque chose il faudra passer par là avant de songer à ditcher root.
Le problème c'est pas ubuntu, c'est que vous êtes des dinosaures (et je ne vois pas trop comment ça peut être gérable d'un point de vue sécu avec des milliers de machines).
[^] # Re: troll
Posté par Psychofox (Mastodon) . Évalué à 5.
Si t'as signé un SLA pour la remise en service en 2h d'un service et que tu n'as pas mis en oeuvre les moyens technique pour le faire tu as un gros problème.
Zones sécurisée, toussa ce sont des excuses. Tu peux avoir un serveur jumpstart et du dhcp dédié à cette zone avec des images adhoc. Ça fait 8ans que je n'ai plus touché à une solaris mais 1h30 ça me parait long pour une install.
# Solution non technique
Posté par Maclag . Évalué à 10.
Je suis pas admin (je ne crois pas que faire marcher 2 yunohost soit une bonne qualification…), ni expert sécurité, mais rien qu'à avoir les questions que tu te poses et les différentes réponses:
-Établis un devis qui indique:
-Les préparatifs pour s'assurer que ce changement majeur se passera bien, y compris sur Solaris: mets-y une bonne patate d'heures, parce que apparemment, tu vas les passer, et une patate de plus pour tous les problèmes non-prévus que nous savons tous que tu vas rencontrer en route…
-Le changement lui-même: 1h
-Les vérifications que rien n'est cassé une fois le changement fait: re-patate d'heures
Mon expérience personnelle (pas en informatique, mais ça ne change pas grand chose): les clients, ça demande un peu tout et n'importe quoi jusqu'à ce que ça se retrouve avec un devis sous le nez…
[^] # Re: Solution non technique
Posté par Fopossum . Évalué à 9.
Ah ah ! :-D
La première réponse compatible SSII :-)
Je t'ai pertinenté pour le coup :-P
cd /pub && more beer
[^] # Re: Solution non technique
Posté par Mimoza . Évalué à 5.
Tu peux jouer aussi la carte procédurière.
Chez ton gros client il semble y avoir une cellule sécurité, renvoie leur la patate chaude, genre "je ne ferais rien sans leur aval". Bon le risque c'est qu'entre chef ils s'arrange pour que l'avis soit positif, donc prend tes précautions avant en allant les voir et orienter leur décision.
# root et buntu
Posté par Beru . Évalué à 9.
" CentOS /RHEL ça pue, que Ubuntu c'est le bien"
Ben je suis pas un génie ni un pro, mais bon, j'ai testé, les différentes distros, mon opinion c'est "chez toi tu installes celle qui convient à tes besoins, pour ta boite c'est la même chose, et tes besoins à la maison ne sont pas les mêmes que ceux de ta boite".
Root or not root…
Sous 'buntu' and co, le seul avantage du "pas root" c'est de te rappeler à chaque manip risquée que tu fais une manip risquée. Le fait de devoir entrer son mot de passe est censé nous freiner un peu.
Dans les faits j'ai fais de grosses bêtises avec 'buntu parce que au bout d'un moment tu prends l'habitude de taper sudo + ton mot de passe pour un oui ou un non. Et pour peu que tu sois fatigué/ énervé, tu rentres ton mot de passe sans réfléchir et bam tu flingues ta machine.
Bref l'idée de buntu était bonne au début mais pas sur le long terme. Z'ont pas tenu compte du facteur humain, enfin pas assez.
Ceci dit, le coup de ton enveloppe scellée avec root… ben ça pourrait faire pareil. L'enveloppe finira ouverte dans un coffre fort ouvert si on a besoin du compte root pour la moindre tâche de maintenance. L'avantage c'est que tu pourras dire au client: "je vous avais prévenu, nous ne sommes donc pas responsable".
Je ne sais pas si c'est possible mais l'idéal serait d'avoir la possibilité d'un niveau de dépannage intermédiaire, et Seulement dans le cas absolu de devoir passer par root.
Et comment je fais moi? Ben sur ma machine j'ai une copie régulière sur un disque pas branché à la machine pour pouvoir tout réinstaller. Et j'espère très fort que un jour j'aurais pas l'idée de faire un sudo hors de propos alors que le disque sera branché pour une copie…
[^] # Re: root et buntu
Posté par fearan . Évalué à 5.
c'était le même problème avec l'UAC sous vista qui se lançait pour un oui ou pour un non, les gens cliquaient bêtement sans lire.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: root et buntu
Posté par Psychofox (Mastodon) . Évalué à 2.
Soit dit en passant si ubuntu propose par défaut de ne pas mettre de mot de passe root, il ne l'interdit pas. Ma boite a une majorité d'ubuntu et on les déploie avec un mot de passe root.
[^] # Re: root et buntu
Posté par damaki . Évalué à 6. Dernière modification le 04 mars 2021 à 08:48.
Sauf qu'au bout d'un moment, t'en a marre de mettre sudo devant chaque commande et tu fais sudo -i ou sudo bash.
[^] # Re: root et buntu
Posté par Yth (Mastodon) . Évalué à 4. Dernière modification le 04 mars 2021 à 08:50.
C'est un peu comme de forcer à confirmer la moindre suppression de fichier.
rm truc -> confirmation
rm -r truc/ -> confirmation, confirmation, confirmation… -> ctrl-c -> rm -rf truc/
Et finalement on saute l'étape rm truc pour taper toujours rm -f truc.
Et là on n'a plus de demande de confirmation pour les fichiers un peu protégés mais qu'on peut effacer quand même.
L'idée est bonne et fonctionne cinq minutes, et après on en revient toujours au même point : fais toujours gaffe à ce que tu fais, et tu ne seras jamais à l'abri d'une fausse manip.
[^] # Re: root et buntu
Posté par _kaos_ . Évalué à 3.
Salut,
Bah :) Ça sert à ça, l'expérience !
Comme déjà dit :
:p
Matricule 23415
[^] # Re: root et buntu
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 04 mars 2021 à 10:13.
Le bon admin c'est celui qui après avoir fait une bêtise l'annonce à son équipe et au client, la répare au plus vite et réalise un post-mortem avec ses collègues après pour comprendre les raisons, limiter le risque que ça se reproduise et améliorer le processus de "remise sur pied".
[^] # Re: root et buntu
Posté par _kaos_ . Évalué à 2.
Salut,
C'était sous-entendu ;)
Matricule 23415
[^] # Re: root et buntu
Posté par Psychofox (Mastodon) . Évalué à 2.
Bon ça ne s'applique pas à du rm ou de la gestion de fichier mais personnellement j'aime mieux les systèmes qui t'imposent d'écrire le nom de la ressource que tu veux supprimer/rebooter quand tu es en interactif.
[^] # Re: root et buntu
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 0.
Merci Molly guard
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Renverser la charge de la preuve
Posté par Mimoza . Évalué à 7.
Apparemment ça demande est motivé uniquement pour alléger sa charge de travail.
Donc tu peux lui répondre un "non" politiquement correcte en lui disant que ça va a l'encontre des pratique de la boite et que sans justification en béton ton devoir de conseil de presta t'interdit de faire une tel manipulation.
Après tu peux la jouer fine en mettant un certain nombre de personne en copie du mail bien choisi (N+2, responsable sécu, etc.) pour qu'il ne puisse pas te répondre "fait le et tais toi".
Au pire tu te prendra une soufflante et tu sera obligé de le faire, au mieux ça va s'enliser administrativement et passé aux oubliettes
# recommandations de l'ANSSI
Posté par eric gerbier (site web personnel) . Évalué à 6.
La demande faite excède largement les recommandations de l'ANSSI qui sont :
R18 : "Le mot de passe root doit être suffisamment robuste compte tenu des recommandations présentes dans la note « Recommandations de sécurité relatives aux mots de
passe » [1].
Ce mot de passe doit être unique et propre à chaque machine.
R19 : Chaque administrateur doit posséder un compte dédié (local ou distant), et ne pas
utiliser le compte root comme compte d’accès pour l’administration du système.
Les opérations de changement de privilèges devront reposer sur des exécutables permettant de surveiller les activités réalisées (par exemple sudo).
# Renommer Root ?
Posté par Shunesburg69 . Évalué à 2.
Bah ce serait pas une mauvaise chose de juste renommer Root ?
Comme ça si vous lui dites que le compte Root n'existe plus, vous ne lui mentirez pas et vous aurez toujours un compte de secours.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.