« GitLab approves the use of Linux, and Apple's macOS. Microsoft Windows is prohibited for the following reasons:
— Due to Microsoft Windows' dominance in desktop operating systems, Windows is the platform most targetted by spyware, viruses, and ransomware.
— macOS is preinstalled on Apple computers and Linux is available free of charge. To approve the use of Windows, GitLab would have to purchase Windows Professional licenses, as Windows Home Edition does not satisfy GitLab's security guidelines.
— As many purchases of laptops have occurred with employees making the purchases and then being reimbursed by GitLab, a remote employee would typically be making a purchase of a laptop pre-loaded with Windows Home Edition.
— Windows Home Edition is notoriously hard to secure. »
Le titre de mon commentaire est interrogatif : en tant que non expert ces motivations me paraissent excellente, et de notoriété publique. Mais vu le nombre d'organisations qui persistent à faire jouer leurs employés au grand jeu des ransomwares, il faut bien supposer qu'elles trouvent d'excellents arguments pour ce faire ?
Posté par Misc (site web personnel) .
Évalué à 8.
Dernière modification le 06/08/22 à 11:33.
Je suppose qu'une bonne part a des admins pour gérer tout le parc. La, j'ai l'impression que les portables sont en gestion par les employés (cf le passage sur "on a besoin d'un screenshot pour prouver que vous avez un disque chiffré", ce qui n'aurait aucun sens si les portables étaient géré par des admins).
Du coup, ça change un peu la donne, et c'est pas tant interdire Windows qu'interdire Windows géré par les utilisateurs.
Dans une grande organisation, tu as en général un département informatique qui va filer des portables sous le contrôle du département, donc capable d'appliquer des GPO (politique de sécurité) avec un annuaire centralisé (eg active directory), etc.
Les grandes organisations achètent leurs ordinateurs par conteneurs entiers, préchargés avec Windows Pro. Ou sinon (ou en plus) elles ont des images Windows Pro prêtes à écraser le Windows Home fourni avec la machine. Elles ont également l'organisation et l'investissement pour gérer les spywares, viruses & co (et fliquer un peu les employés au passage), et un poids suffisant auprès de Microsoft pour heu disons discuter en cas de problème.
Les petites organisations, quand elles ne sont pas 100% Apple, gèrent certainement au feeling quelques installations Windows (avec une mauvaise sécurité) et n'ont probablement pas la compétence de gérer un parc Linux. Elles ne persistent en rien, elles ne savent pas faire.
un poids suffisant auprès de Microsoft pour heu disons discuter
en cas de problème.
Le terme que tu cherches est sans doute "contrat de support".
Je pense qu'on se rends pas trop compte du gouffre qu'il y a entre les offres pas cher grand public (exemple, la téléphonie, l’accès internet) avec un support minimal et les offres pro plus cher, justement, parce que quelqu'un paye pour le support (et parce que le support, ça coûte de l'argent).
On a eu le témoignage récemment (lien posté sur linuxfr) qu'on peut payer très cher pour ne pas avoir du support (plus exactement, pour ce cas, y avait pas le support krosoft mais Rubrik a sauvé la mise…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Exact ! Je n'avais pas eu le temps de chercher pour mettre un lien sur mon propos. Il y a d'autres exemples comme ça (pas sur leur problème exactement hein, mais sur le support inopérant en général) même si on n'en parle pas forcément (aucun des cas que j'ai connu en entreprises, par exemple, n'a été publié sur la toile, et en discutant avec d'autres personnes du métier ce ne sont pas forcément des cas isolés.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
De toute manière on est en grande pénurie d'admins. Les écoles
crachent des dev par milliers, des admins, non.
Ensuite, l'administration système n'est pas vu comme attractive.
Ça paye moins qu'un dev (de ce que j'ai vu en parlant salaire avec les collégues, et en regardant des chiffres , la profession donne l'image de râleurs qui vont dire "non" (voir directement de connards, et il faut dire la vérité, c'est parfois non usurpé), le business ne va pas te voir comme générateur de valeur mais comme un coût.
Les grandes boites du net (style Google, facebook) ont repris l'idée de l'administration systéme mais en rajoutant "fait par des devs" sous le terme "devops", comme si les adminsys n'avaient jamais rien codé avant.
Et on va associer l'adminsys avec le fait d'avoir des astreintes, donc des contraintes un peu naze.
Donc franchement, faut pas se plaindre des écoles. Si on voulait plus d'admin, on pourrait payer plus et former les gens sans dépendre de l'éducation national. Le fait est que ça n'est pas ce qui est fait, donc la pénurie doit pas être si problématique que ça.
Les grandes boites du net (style Google, facebook) ont repris l'idée de l'administration systéme mais en rajoutant "fait par des devs" sous le terme "devops", comme si les adminsys n'avaient jamais rien codé avant.
Que dans les boîtes qui n'ont pas compris ce qu'est le devops. Le devops est une organisation pour supprimer
la profession donne l'image de râleurs qui vont dire "non" (voir directement de connards, et il faut dire la vérité, c'est parfois non usurpé)
Tu t'organise pour que les devs et les admins ne travaillent pas comme client l'un de l'autre mais collaborent pour fournir le service et ça peut impliquer de fusionner les équipes.
Le fait de produire quelque chose de différent avec ce type d'organisation qu'avant n'est qu'un effet de bord et pas un objectif.
[adminsys], le business ne va pas te voir comme générateur de valeur mais comme un coût.
En France, pour ce que j'ai constaté, l'informatique plus généralement est considéré comme un centre de coûts à minimiser (à défaut d'arriver à rendre cela nul…)
Les grandes boites du net (style Google, facebook) ont repris l'idée de l'administration systéme mais en rajoutant "fait par des devs" sous le terme "devops", comme si les adminsys n'avaient jamais rien codé avant.
Attention que l'administration système fait par des devs pour des devs est un glissement marketing (donc de la pub mensongère ou presque) qui permet d'attraper le chaland qui va pouvoir se dire « économisons sur la partie système et obtenons encore plus des devs en leur faisant faire du système avec ça »
Mais devops initialement n'est pas (que) des outils et de l'idéologie mais diverses formes de méthodologie pour arriver à faire travailler ensemble les gens du système (= on privilégie la stabilité de la prod et on veut que tout déploiement soit maîtrisé et donc préférer freiner tout ce qui déborde ou ne va pas dans ce sens) et du développement (= on privilégie la livraison de fonctionnalités et des temps de livraison raccourcis au max —time to market oblige— et on ignore tout des contraintes systèmes qui au passage nous passent par dessus et n'est pas notre taf) Le but initial était de casser un peu plus les silos (on peut le voir comme le passage de bureaux cloisonnés à l'open space) et de créer de la synergie (comme une grosse équipe de divers spécialistes contrairement aux petites équipes spécialisées d'avant) là où chacun (sys et dev) voyait l'autre comme bloquant/cassant. On s'en éloigne (et supprimant si possible les sysadmins)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
En vérité on ne supprime pas les sysadmins, ce sont les sysadmins qui se reconvertissent.
De toute façon avec la culture agile, les processus gitops et infra as code le travail du sysadmin a lentement glissé ces 15 dernières années pour se rapprocher du développement. Les sysadmins ont toujours du "coder" pour se faciliter la vie notamment avec des scripts shells, perl puis python mais maintenant l'organisation même des équipes et du travail amène à une convergence naturelle.
C'est surtout que ça dit toujours la même chose, en pratique que le seul gain qu'ils voient en Linux est qu'il est peu utilisé donc pas la plate-forme visée en premier. Pas sympa pour Linux.
Bon, à un moment j'aimais bien GitLab mais ces derniers temps il y a des détails qui montrent que ça part parfois dans des délires…
Bon, sinon, comme télétravail chez eux, pour leur faire plaisir mon laptop serait sous Windows pour les trucs de tous les jours (y compris mes recherches d'aide technique sur le net) avec un VM Linux pour la partie développement à afficher (et si pas de truc spécifique Linux, la capture d'écran pour faire plaisir et le reste du temps travail sous Windows). Ce genre d'interdiction me rappelle les années 90, quand Internet était interdit ou limité parce que les experts sécurité voulaient protéger la boite, les gens branchaient un modem à côté sans aucune supervision (vu que c'était interdit on n'allait pas informer) et sans sentiment coupable (l'équipe sécurité fait chier à empêcher de faire son travail) et bam les virus passaient par la. A un moment les équipes de sécurités comprenaient qu'il ne fallait pas bloquer pour bloquer mais accompagner pour éviter que les salariés aient à se débrouiller autrement (et moins sécurisé), faut croire que l'histoire est un éternel recommencement.
Notons au passage que les ransomwares ne font des dégâts que quand l'équipe sécurité est merdique et ne fait pas son travail (les backups non modifiables, cloisonnés, indépendants de ce que la machine du salarié se prend; on reset la machine et sort le backup, et on est reparti).
Le problème des rançongiciels n'est pas que la perte des données, ça fait quand même un certain temps qu'ils pratiquent la double, voire triple, extorsion en menaçant de publier les données récupérées (donc sanction RGPD et diffusion du savoir-faire de l'entreprise).
GitLab a tout ce qui est utile à ses devs en public donc la valeur de diffuser le code… ;-) C'est un des avantage du "source available" (libre ou pas, pas le sujet, pour faire râler les libristes pensant que tous les avantages du libre sont grâce au libre) et des trackers publics.
Reste les données "sensibles" sujet au RGPD, mais il ne doit y avoir que quelques personnes dans la boite qui y a accès et si ceux-la n'ont pas la formation pour ne pas cliquer sur un lien bizarre dans un e-mail, le problème est ailleurs…
Au final, quand on prépare bien et qu'on est ouvert il reste la perte de quelques heures de travail par personne pour repartir à partir d'une machine vierge, changer sa clé SSH et ses passes partout, et c'est tout.
sanction RGPD
Par curiosité, quelles sanctions? A ma connaissance tu dois informer des données dans la nature et les sanctions sont surtout si tu n'informes pas ou que tu n'as pas eu une sécurité qui corresponde à la sensibilité (genre si tu as gardé les mots de passe en clair, ou les numéros de sécu à tous les devs "pour un jeu de test", que tout le monde a accès à la prod), pas à la fuite en elle-même.
Il y a toujours des donnée sensibles : informations sur ton infrastructure, code spécifique (version plus complète payante, outils d’admin sys, …), fiches de salaire, base des clients et offres commerciales, nouveaux projets, stratégie pour les années à venir, …
Sans compter les conséquences pour l’image de la boîte.
Quant à résumer les attaques à de simples liens douteux… c’est bien méconnaître les attaques cybercriminelles. Un bon hameçonnage va arriver après plusieurs échanges et sera convaincant. Ou alors ton commercial n’ouvre jamais le moindre devis envoyé en PDF, mais alors j’ai un doute sur son travail.
La sanction RGPD peut tomber pour défaut de sécurisation, indépendamment de la déclaration CNIL.
Les salariés Gitlab sont en 100% télétravail. Ils n'ont pas accès à un service informatique physique pour dépanner, ce qui implique que chacun soit suffisamment autonome avec son portable. Ça n'empêche pas d'avoir une administration distante, mais ça limite quand même (les admins sont aussi en 100% distants les uns des autres et vis-à-vis des utilisateurs, tu rajoutes pas une barrette de RAM en 5min ou remplaces un disque ssd sans l'utilisateur…).
En pratique, c'est pas l'admin qui va faire ça, mais le support du fabricant. Et en général, tu ne rajoutes pas du matos aprés l'achat, tu t'arranges pour que ça soit directement fait avant la livraison.
Les revendeurs qui servent d’intermédiaire à Dell/Lenovo/etc font ça sans souci (ou peut être que c'est directement chez le fabricant).
Alors, ça dépend. Ça peut être fait par les services de la boîte pour du remplacement (pas pour le setup initial). Ça évite de devoir se farcir un aller-retour chez le fabricant au moindre soucis (comme pour les serveurs physiques d'ailleurs).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Le service informatique de ma boîte a déjà rajouté une barrette de RAM sur mon vénérable portable (j'ai une tendance marquée à garder le matériel longtemps). Et a changé la batterie qui avait gonflé et déformé le boîtier. Je fais le moins possible appel à eux, mais parfois c'est pratique de réparer en 10 min… Le télétravail est moins pratique pour ça.
Je suis en télétravail et quand j'ai voulu doubler la ram de mon laptop, mon service technique m'a simplement demandé si je voulais le faire moi-même ou pas. J'ai dis oui et ils m'ont envoyé les barrettes mais sinon ils m'auraient dis d'aller chez un revendeur agréé lenovo. Ce n'est pas vraiment compliqué non.
Oui, quand j’étais sur ce genre de poste pendant 2 ans et demi, je l'ai déjà fait aussi parce que je sais le faire et que j'étais la. Contrairement à ce qu'on pourrais croire, les gens du support ne sont pas des monstres.
Ensuite, quand je n'étais pas la ou dans les bureaux sans service informatique sur place, ça passe par le fabriquant, ou les gens le font eux même.
Ensuite, on parle des Lenovos, qui sont facile à modifier (plus ou moins). Je pense que pour les macbooks, c'est direction le genius bar le plus proche (et ça doit être compris dans le support applecare, vu qu'une boite va payer pour ça).
Microsoft Windows is prohibited for the following reasons:
— Due to Microsoft Windows' dominance in desktop operating systems, Windows is the platform most targetted by spyware, viruses, and ransomware.
Cette raison là est vraiment nulle. Si Linux devient majoritaire, tu vas faire retourner ta boîte sur Windows pour éviter le ciblage des attaquants ? Jouer à cache-cache avec les attaquants en se réfugiant dans les systèmes moins connus, c'est le meilleur moyen d'épuiser ton support informatique et de te donner une fausse sensation de sécurité.
Linux est tout à fait en mesure de fournir des environnements fortement sécurisés. Pourquoi le renier en faisant valoir à la place une analyse d'intérêts au doigt mouillé comme ça ?
Libriste ne veut pas dire dogmatique, des fois on sait juste accepter qu'un truc ne répond pas encore au besoin en libre.
Rien de nouveau sous le soleil (coucou les dogmatique "pas de code non libre chez moi" mais qui ont leur BIOS, le truc le plus sensible en terme de sécurité, en non libre, bref des dogmatiques qui critiquent la frontière accepté par le voisin en oubliant qu'il ne fait que mettre la frontière ailleurs, le principe ne change pas entre les 2 personnes, toujours une frontière pour accepter du non libre, juste le curseur pas au même endroit).
En pratique GitLab joue le jeu de l'ouverture de leur code à fond (beaucoup de code libre, et ce qu'ils font en non libre est faisable aussi par les autres avec les mêmes règles, contrairement à ceux qui utilisent des licences libres pour s'afficher libriste mais profitent de licences qui limitent pour bloquer les autres de faire comme eux en profitant qu'ils ont des droits qu'ils ne partagent pas).
qui ont leur BIOS, le truc le plus sensible en terme de sécurité
Je suis pas d'accord. Le BIOS n'est pas "le plus sensible en terme de sécurité".
Deja, c'est loin d'être le plus exposé des logiciels ni le plus exploité. Il ne traite pas des données complexes venant du réseau, ses seuls inputs vont être le hardware au démarrage.
Et il suffit de remplacer "BIOS" par "grub" (qui est le suivant dans la chaine) dans la phrase pour voir que c'est totalement creux comme discours sauf dans l'esprit enfiévré d'une partie de la communauté du libre qui pense que la NSA et le Mossad s'intéresse à eux.
Pas chez toi, mais dans certaines structures où on ne veut que seules les personnes dument autorisées aient accès à la machine le BIOS a son importance.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
"pas le plus sensible", ça veut pas dire "on s'en balek".
Ça veut juste dire que dans un classement, c'est pas en haut.
La preuve, pendant des années, on a pas eu de mécanismes simples de mises à jour du BIOS ou de l'UEFI (eg, fwupdate sous Linux), et que je sache, on a pas eu d'apocalypse, et que je voudrais bien dire "le nombre de souci de sécurité lié à un souci dans le BIOS se compte sur les doigts d'une main", mais j'ai rien qui me vient à l'esprit.
À coté de ça, on a eu plus de gens qui ont eu des soucis à cause des certificats et du manque de TLS, on eu plus de souci suite à des soucis de crypto (la faille openssh de debian en 2008), etc.
Ensuite, si tu veux éviter le homebrew sur ton matériel, oui. si tu es Google, Amazon ou Nintendo ou n'importe qui qui veut controler le matériel face à ses users, oui, il te faut un BIOS blindé.
Dans une console de jeux, le BIOS va importer à mort. Mais que je sache, on parle pas de ça ici. Et non seulement on parle pas de ça, mais en plus, si on en parle, on va en parler pour la perte de liberté que ça entraîne (eg, secureboot par défaut sur les trucs ARM, etc).
Primo, c'est un rootkit UEFI. Techniquement, c'est pas du BIOS, mais je vais pas jouer sur les mots. Mais surtout, la présence d'un rootkit possible est assez séparé de la question de la sécurité.
Pour utiliser ce genre de rootkit, tu as 2 choix.
Le premier, c'est un accès physique avec assez de temps pour installer le rootkit. C'est assez spécifique, mais si tu peux reflasher la puce mémoire, alors on peut supposer que tu peux installer le rootkit en question, et c'est indépendant du code du BIOS/UEFI et de sa sensibilité vu qu'il va se faire écraser et/ou augmenter.
eg., ce qui est sensible, c'est pas le BIOS/UEFI mais la carte mère (et le fait d'accepter des BIOS/UEFI non signé, ou signé par des clés qu'on peut trouver facilement, etc)
L'autre choix, c'est de flasher depuis l'OS. La, on peut avoir une discussion sur savoir si c'est plus sur de ne pas pouvoir remplacer un logiciel (car en read-only dans une ROM) sachant que ça implique aussi de ne pas pouvoir le patcher en cas de pépin. Mais pareil, le fait de flasher ou pas n'est pas aussi important que le fait que ça implique d'avoir une faille avant pour exécuter du code ce qui rends à mon sens l'userspace plus sensible.
Si j'ai uniquement une faille userspace, je peux te voler des infos, avec ou sans faille dans le BIOS/UEFI. Si j'ai qu'une faille UEFI/BIOS, bah, je suis quand même bien coincé en tant qu'attaquant.
La, l'exemple parle d'une attaque sur le firmware, mais à part la persistance qui se fait au niveau de l'UEFI, il n'y a rien de spécial qui va montrer que l'UEFI est le plus sensible. Si je fais un implant qui persiste via cron, est ce que crond devient "le plus sensible en terme de sécurité" ?
Même si le code de l'UEFI était blindé à mort avec 5 signatures incassables et 0 failles de sécurité, ç'est un implant qui est transmis par le fabricant. Tu peux pas faire grand chose contre ça, et ça marcherais aussi bien avec un pilote d'imprimante ou n'importe quoi d'autre.
Du coup, je suis pas sur de piger exactement le point que tu cherches à démontrer par ton lacunaire Ahem.
La, par exemple, je pense que le fabricant est plus sensible en terme de sécurité que le BIOS d'une machine, surtout parce que le fabriquant s'est fait poutré et que ce genre d'attaques arrivent, alors que des attaques sur le BIOS (ou l'UEFI), y en a 0.
Et un implant, c'est pas une attaque. Pas plus que mettre un rootkit serait une attaque sur le kernel, sur une distro ou sur le projet GNU.
Mais je suis d'accord sur la 2eme partie de ton commentaire.
En effet, tout le monde peut se tromper, mais je pense tu n'avais pas besoin d'en fait la démonstration par l'exemple avec ton début de commentaire.
Posté par FantastIX .
Évalué à 4.
Dernière modification le 09/09/22 à 23:42.
Techniquement, c'est pas du BIOS, mais je vais pas jouer sur les mots.
En effet. On ne parle plus de BIOS depuis quelque temps, terme qui est à présent remplacé par "firmware", soit [U]EFI.
la présence d'un rootkit possible est assez séparé de la question de la sécurité.
Pardon? En quoi un rootkit, potentiellement ou pas, et qui, par définition, sert de porte dérobée à l'accès d'un système à l'insu de son propriétaire est "assez éloigné de la question de la sécurité"??? Franchement, je suis abasourdi par une affirmation pareille. Ou c'est moi qui pige pas ou c'est toi. Ou autre encore que je vois pas mais tu vas devoir détailler. C'est quoi "la sécurité" pour toi?
Le premier, c'est un accès physique avec assez de temps pour installer le rootkit. C'est assez spécifique, mais si tu peux reflasher la puce mémoire, alors on peut supposer que tu peux installer le rootkit en question, et c'est indépendant du code du BIOS/UEFI et de sa sensibilité vu qu'il va se faire écraser et/ou augmenter.
Ton argumentation est à côté de la plaque et j'ai le sentiment que tu essaies d'argumenter n'importe quoi pour t'en sortir. L'attaque UEFI permet, justement de passer sous le radar¹ et de s'installer de façon permanente, en altérant les composants qui interviennent dans le chargement de l'OS (plus particulièrement du noyau). Et, au cas où tu souhaiterais le nier, peu importe le mode d'accès utilisé par l'attaque UEFI ou le niveau de difficulté à y parvenir: dès que l'ordi est compromis, c'est mort, contrairement aux autres attaques, où une réinstallation des composants logiciels (système d'exploitation) est suffisante pour purger le système des éléments compromis. Avec une attaque UEFI, rien ne garantit qu'une réinstallation du micrologiciel soit suffisante, pour autant qu'elle soit possible. Tout dépend de son degré de sophistication.
Alors si ça n'est pas suffisamment argumenté contre l'affirmation "le BIOS firmware (ou micrologiciel) n'est pas le plus sensible […]" à la faveur de "le firmware est [au moins] aussi sensible que le reste", je ne sais pas ce qu'il te faux. Non, faut, pardon :-D … Parce que, tu vois, si j'étais un pirate informatique, je m'arrangerais pour développer à la [quasi] perfection ma solution d'attaque de cette section de l'ordinateur².
L'autre choix, c'est de flasher depuis l'OS. La, on peut avoir une discussion sur savoir si c'est plus sur de ne pas pouvoir remplacer un logiciel (car en read-only dans une ROM) sachant que ça implique aussi de ne pas pouvoir le patcher en cas de pépin. Mais pareil, le fait de flasher ou pas n'est pas aussi important que le fait que ça implique d'avoir une faille avant pour exécuter du code ce qui rends à mon sens l'userspace plus sensible.
Je ne vois pas où tu veux en venir.
Mais tu parles de quoi, au juste? Des ordinateurs "modernes" (vendus après 2000) ou bien de ces vieilleries qui tournaient avec un BIOS en mémoire EPROM? Parce que 1) on ne vend plus ces antiquités depuis lulure et 2) les dernières versions de Windows qui tournaient dessus sont Windows 7, plus vendu non plus (même si on en trouve encore). Et, par extension, qu'est-ce que t'essaies de démontrer? Que les vieux chariots ont un BIOS moins vulnérables que les nouveaux? Si c'est ça, y a pas besoin d'argumenter, c'est une porte ouverte que je me garderais bien d'enfoncer…
Si j'ai uniquement une faille userspace, je peux te voler des infos, avec ou sans faille dans le BIOS/UEFI. Si j'ai qu'une faille UEFI/BIOS, bah, je suis quand même bien coincé en tant qu'attaquant.
Ah???? T'as déjà essayé? Non, je veux dire, pour de vrai et sans partir du principe/de l'a priori que c'est mort. Parce que si oui, ça veut dire que les concepteurs de CosmicStrand (pour commencer mais il y en a d'autres, bien d'autres) ont développé une solution sophistiquée pour pas grand chose. Franchement, j'ai un doute.
La, l'exemple parle d'une attaque sur le firmware, mais à part la persistance qui se fait au niveau de l'UEFI, il n'y a rien de spécial qui va montrer que l'UEFI est le plus sensible. Si je fais un implant qui persiste via cron, est ce que crond devient "le plus sensible en terme de sécurité" ?
Faisons un brin de logique, veux-tu: démontrer que l'affirmation "le BIOS n'est pas le composant le plus sensible" est fausse ne revient pas à démontrer que "le BIOS est le composant le plus sensible" est une affirmation vraie. S'il est aussi sensible que le reste (c'est ce que je défends comme position), alors ton affirmation est fausse, sans qu'il soit nécessaire de démontrer que "c'est le composant le plus sensible".
Garde quand même à l'esprit que si le firmware se fait plomber, le PC est bon pour le bac ou pour servir de banque de composants électroniques de réparation, façon Rossmann Group…
Même si le code de l'UEFI était blindé à mort avec 5 signatures incassables et 0 failles de sécurité, ç'est un implant qui est transmis par le fabricant. Tu peux pas faire grand chose contre ça, et ça marcherais aussi bien avec un pilote d'imprimante ou n'importe quoi d'autre.
Rien ne démontre que l'implantation d'un malware UEFI n'est possible que chez le fabricant; les fuites de clés (privées) et l'usurpation d'identité/certificat électronique, ça existe aussi. Le cas que j'ai cité, CosmicStrand n'est qu'un exemple dont j'eus souhaité qu'il te parlât suffisamment pour éviter de raconter n'importe quoi. Je n'ai peut-être pas suffisamment insisté ou fourni de sources…
Du coup, je suis pas sur de piger exactement le point que tu cherches à démontrer par ton lacunaire Ahem.
Qu'il est faux d'affirmer "le BIOS n'est pas le composant le plus sensible".
La, par exemple, je pense que le fabricant est plus sensible en terme de sécurité que le BIOS d'une machine, surtout parce que le fabriquant s'est fait poutré et que ce genre d'attaques arrivent, […]
Tu te bases uniquement sur CosmicStrand, faisant par là même un biais de sélection pour ton raisonnement. Est-ce le seul malware ciblant les firmwares? Je te laisse trouver par toi-même.
alors que des attaques sur le BIOS (ou l'UEFI), y en a 0
Rhoooo, dis, à ce stade, c'est vraiment de la mauvaise foi, hein?
Et un implant, c'est pas une attaque. Pas plus que mettre un rootkit serait une attaque sur le kernel, sur une distro ou sur le projet GNU.
Qu'un implant ne soit pas une attaque (ce qui est une affirmation encore plus discutable) n'invalide en rien que ton affirmation est fausse depuis le début. Cependant, je commence à envisager que nous n’ayons pas la même définition du mot "sensible" …
Mais je suis d'accord sur la 2eme partie de ton commentaire.
En effet, tout le monde peut se tromper, mais je pense tu n'avais pas besoin d'en fait la démonstration par l'exemple avec ton début de commentaire.
C'te bonne paire. Forcément…
Raisonnement circulaire bouclé, puisque, par définition, tu estimes depuis le début que c'est moi qui me plante.
Je te propose d'en rester là, puisque nous sommes tous deux d'avis que c'est l'autre qui a tort et que rien ne semble nous faire changer de position. Alors allons nous asseoir chacun de notre côté, câliner notre chérie ou prendre un pot, c'est comme tu veux. En ce qui me concerne, en tous cas, cette discussion me fatigue.
¹ Notamment en raison de la quasi inexistence des outils de détection appropriés.
² Je te suggère, vigoureusement, de visionner les conférences Black Hat si tu ne les connais pas encore. À titre informatif, ce que j'y ai vu m'a tout simplement laissé sur le cul.
³ Ça m'a pris seulement 3 secondes sur duckduckgo.com…
ok, du coup tu dirais quoi? (puisque bon, BIOS corrompu ==
plein de complications pénibles à gérer ensuite)
Un BIOS corrompu (l'exemple du virus CIH de 1998 me vient en tête), ça serait comme du matos qui tombe en panne, sauf qu'on peut le réparer en reflashant.
Mais on peut imaginer pareil en terme de dégat sur le firmware du disque dur. En fait, c'est pire parce qu'un disque dur corrompu, ça va me coûter plus qu'un BIOS corrompu, vu que je peux changer la carte mère et voila. Sortir les données d'un disque foutu, ça coûte un chouia plus cher.
C'est pas le BIOS. L'iLO tourne sur un processeur à part sur une carte à part avec un OS à part (voir quasiment un Linux embarqué).
Je veux bien qu'on compte ça dans le BIOS sous le prétexte que ça vient avec le matériel dans ton serveur, mais ça serait un abus de langage.
Ensuite, si tu parles de la fonctionnalité équivalente pour les proc intel (eg, AMT), ça vient avec le processeur, pas avec le BIOS. Encore une fois, je veux bien qu'on compte tout qui est avant grub comme "le BIOS" mais ça serait toujours un abus de langage.
Est ce que le BIOS est plus sensible que le processeur ?
Je pense que non (et c'est pour ça aussi que je dit que le BIOS n'est pas le plus sensible en terme de sécurité), mais si on dit "le BIOS est le plus sensible en terme de sécurité", alors le processeur l'est moins. Et c'est pas ce que je voit vu le foin autour des procs intels.
Ensuite, si l'affirmation est "le plus sensible en terme de sécurité, c'est le matériel", l'omniprésence de matériel et/ou de firmware non libre me laisse croire que c'est pas si sensible que ça par rapport au logiciel.
Le matos est la, il est en vente, mais pourtant, j'ai pas le sentiment que ça se bouscule pour acheter (vu qu'il n'y a que Leah sur le coup depuis des années).
Le paranoïaque est il le seul à penser l'être suffisamment?
Je sais pas, je suis pas psychologue, faut aller voir le DSM.
Dire qu'il "suffit" de reflasher est d'une telle incorrection que ça passe sous silence les vers suffisamment sophistiqués pouvant aller jusqu'à rendre inopérant le firmware (pour ne citer que ça). Et dans ce cas, le flashage est impossible.
Il s'implique dans qbrewage (ou un truc comme ça) avec abnégation :-D
Et sinon, beaucoup préfèrent du café au thé (je suis théine aussi, mais encore mieux si je peux avoir un jus de fruit pressé, parmis ceux riche en vitamine C si c'est pour le boost)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Un vrai libriste, c'est un mec qui se fout pas mal de l'informatique, qui préfère la nature et écouter gazouiller les petits oiseaux dans le doux clapotis du ruisseau passant sous les branches du chêne centenaire.
Le faux libriste, c'est celui qui s'achète un ordinateur et en devient l'esclave.
Alors qu'une vraie libriste c'est une bibliothèque partagée avec son petit .so mignon, ses versions majeur/mineur/patch et ses liens symboliques, qui évite le DLL hell et qui est fournie empaqueté avec le système ?
Tandis qu'une FOSS libriste, c'est une extrême radicale en ouverture et liberté.
Le faux libriste lui achète un mac et n'installe pas linux dessus.
J'ai un MacBook, il y a macOS dessus parce que c'est ma machine du quotidien et de MAO. Par contre j'ai un Thinkpad, un Thinkcentre et une multitude de Raspberry Pi sous OpenBSD (projet auquel je donne 10€ par mois), suis-je fiché non-libriste ?
J'espère tout de même que mes contributions à Alpine me garde toujours dans le domaine du libriste malgré ma vilaine acquisition d'un MacBook !
git is great because linus did it, mercurial is better because he didn't
# De bonnes raisons ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
Le titre de mon commentaire est interrogatif : en tant que non expert ces motivations me paraissent excellente, et de notoriété publique. Mais vu le nombre d'organisations qui persistent à faire jouer leurs employés au grand jeu des ransomwares, il faut bien supposer qu'elles trouvent d'excellents arguments pour ce faire ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . Évalué à 8. Dernière modification le 06/08/22 à 11:33.
Je suppose qu'une bonne part a des admins pour gérer tout le parc. La, j'ai l'impression que les portables sont en gestion par les employés (cf le passage sur "on a besoin d'un screenshot pour prouver que vous avez un disque chiffré", ce qui n'aurait aucun sens si les portables étaient géré par des admins).
Du coup, ça change un peu la donne, et c'est pas tant interdire Windows qu'interdire Windows géré par les utilisateurs.
Dans une grande organisation, tu as en général un département informatique qui va filer des portables sous le contrôle du département, donc capable d'appliquer des GPO (politique de sécurité) avec un annuaire centralisé (eg active directory), etc.
C'est pas la direction que gitlab a pris.
[^] # Re: De bonnes raisons ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Dans les organisation, l'adage dit que nul décideur informatique n'a été viré pour avoir signé du petit mou.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: De bonnes raisons ?
Posté par Boa Treize (site web personnel) . Évalué à 9.
Les grandes organisations achètent leurs ordinateurs par conteneurs entiers, préchargés avec Windows Pro. Ou sinon (ou en plus) elles ont des images Windows Pro prêtes à écraser le Windows Home fourni avec la machine. Elles ont également l'organisation et l'investissement pour gérer les spywares, viruses & co (et fliquer un peu les employés au passage), et un poids suffisant auprès de Microsoft pour heu disons discuter en cas de problème.
Les petites organisations, quand elles ne sont pas 100% Apple, gèrent certainement au feeling quelques installations Windows (avec une mauvaise sécurité) et n'ont probablement pas la compétence de gérer un parc Linux. Elles ne persistent en rien, elles ne savent pas faire.
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . Évalué à 4.
Le terme que tu cherches est sans doute "contrat de support".
Je pense qu'on se rends pas trop compte du gouffre qu'il y a entre les offres pas cher grand public (exemple, la téléphonie, l’accès internet) avec un support minimal et les offres pro plus cher, justement, parce que quelqu'un paye pour le support (et parce que le support, ça coûte de l'argent).
[^] # Re: De bonnes raisons ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
On a eu le témoignage récemment (lien posté sur linuxfr) qu'on peut payer très cher pour ne pas avoir du support (plus exactement, pour ce cas, y avait pas le support krosoft mais Rubrik a sauvé la mise…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: De bonnes raisons ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
Évoquiez-vous le cas Manutan ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: De bonnes raisons ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Exact ! Je n'avais pas eu le temps de chercher pour mettre un lien sur mon propos. Il y a d'autres exemples comme ça (pas sur leur problème exactement hein, mais sur le support inopérant en général) même si on n'en parle pas forcément (aucun des cas que j'ai connu en entreprises, par exemple, n'a été publié sur la toile, et en discutant avec d'autres personnes du métier ce ne sont pas forcément des cas isolés.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: De bonnes raisons ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Où se trouve ces compétences ? Ma boite a ouvert un poste pour gérer ses postes Linux et ne trouve personne :(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: De bonnes raisons ?
Posté par Psychofox . Évalué à 10.
J'imagine parce que c'est payé beaucoup moins que d'être sysadmin ou dev/cloudops.
De toute manière on est en grande pénurie d'admins. Les écoles crachent des dev par milliers, des admins, non.
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . Évalué à 10.
Ensuite, l'administration système n'est pas vu comme attractive.
Ça paye moins qu'un dev (de ce que j'ai vu en parlant salaire avec les collégues, et en regardant des chiffres , la profession donne l'image de râleurs qui vont dire "non" (voir directement de connards, et il faut dire la vérité, c'est parfois non usurpé), le business ne va pas te voir comme générateur de valeur mais comme un coût.
Les grandes boites du net (style Google, facebook) ont repris l'idée de l'administration systéme mais en rajoutant "fait par des devs" sous le terme "devops", comme si les adminsys n'avaient jamais rien codé avant.
Et on va associer l'adminsys avec le fait d'avoir des astreintes, donc des contraintes un peu naze.
Donc franchement, faut pas se plaindre des écoles. Si on voulait plus d'admin, on pourrait payer plus et former les gens sans dépendre de l'éducation national. Le fait est que ça n'est pas ce qui est fait, donc la pénurie doit pas être si problématique que ça.
[^] # Re: De bonnes raisons ?
Posté par barmic 🦦 . Évalué à 3.
Que dans les boîtes qui n'ont pas compris ce qu'est le devops. Le devops est une organisation pour supprimer
Tu t'organise pour que les devs et les admins ne travaillent pas comme client l'un de l'autre mais collaborent pour fournir le service et ça peut impliquer de fusionner les équipes.
Le fait de produire quelque chose de différent avec ce type d'organisation qu'avant n'est qu'un effet de bord et pas un objectif.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: De bonnes raisons ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
En France, pour ce que j'ai constaté, l'informatique plus généralement est considéré comme un centre de coûts à minimiser (à défaut d'arriver à rendre cela nul…)
Attention que l'administration système fait par des devs pour des devs est un glissement marketing (donc de la pub mensongère ou presque) qui permet d'attraper le chaland qui va pouvoir se dire « économisons sur la partie système et obtenons encore plus des devs en leur faisant faire du système avec ça »
Mais devops initialement n'est pas (que) des outils et de l'idéologie mais diverses formes de méthodologie pour arriver à faire travailler ensemble les gens du système (= on privilégie la stabilité de la prod et on veut que tout déploiement soit maîtrisé et donc préférer freiner tout ce qui déborde ou ne va pas dans ce sens) et du développement (= on privilégie la livraison de fonctionnalités et des temps de livraison raccourcis au max —time to market oblige— et on ignore tout des contraintes systèmes qui au passage nous passent par dessus et n'est pas notre taf) Le but initial était de casser un peu plus les silos (on peut le voir comme le passage de bureaux cloisonnés à l'open space) et de créer de la synergie (comme une grosse équipe de divers spécialistes contrairement aux petites équipes spécialisées d'avant) là où chacun (sys et dev) voyait l'autre comme bloquant/cassant. On s'en éloigne (et supprimant si possible les sysadmins)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: De bonnes raisons ?
Posté par Psychofox . Évalué à 5.
En vérité on ne supprime pas les sysadmins, ce sont les sysadmins qui se reconvertissent.
De toute façon avec la culture agile, les processus gitops et infra as code le travail du sysadmin a lentement glissé ces 15 dernières années pour se rapprocher du développement. Les sysadmins ont toujours du "coder" pour se faciliter la vie notamment avec des scripts shells, perl puis python mais maintenant l'organisation même des équipes et du travail amène à une convergence naturelle.
[^] # Re: De bonnes raisons ?
Posté par Zenitram (site web personnel) . Évalué à -1.
C'est surtout que ça dit toujours la même chose, en pratique que le seul gain qu'ils voient en Linux est qu'il est peu utilisé donc pas la plate-forme visée en premier. Pas sympa pour Linux.
Bon, à un moment j'aimais bien GitLab mais ces derniers temps il y a des détails qui montrent que ça part parfois dans des délires…
Bon, sinon, comme télétravail chez eux, pour leur faire plaisir mon laptop serait sous Windows pour les trucs de tous les jours (y compris mes recherches d'aide technique sur le net) avec un VM Linux pour la partie développement à afficher (et si pas de truc spécifique Linux, la capture d'écran pour faire plaisir et le reste du temps travail sous Windows). Ce genre d'interdiction me rappelle les années 90, quand Internet était interdit ou limité parce que les experts sécurité voulaient protéger la boite, les gens branchaient un modem à côté sans aucune supervision (vu que c'était interdit on n'allait pas informer) et sans sentiment coupable (l'équipe sécurité fait chier à empêcher de faire son travail) et bam les virus passaient par la. A un moment les équipes de sécurités comprenaient qu'il ne fallait pas bloquer pour bloquer mais accompagner pour éviter que les salariés aient à se débrouiller autrement (et moins sécurisé), faut croire que l'histoire est un éternel recommencement.
Notons au passage que les ransomwares ne font des dégâts que quand l'équipe sécurité est merdique et ne fait pas son travail (les backups non modifiables, cloisonnés, indépendants de ce que la machine du salarié se prend; on reset la machine et sort le backup, et on est reparti).
[^] # Re: De bonnes raisons ?
Posté par flan (site web personnel) . Évalué à 3.
Le problème des rançongiciels n'est pas que la perte des données, ça fait quand même un certain temps qu'ils pratiquent la double, voire triple, extorsion en menaçant de publier les données récupérées (donc sanction RGPD et diffusion du savoir-faire de l'entreprise).
[^] # Re: De bonnes raisons ?
Posté par Zenitram (site web personnel) . Évalué à 0.
GitLab a tout ce qui est utile à ses devs en public donc la valeur de diffuser le code… ;-) C'est un des avantage du "source available" (libre ou pas, pas le sujet, pour faire râler les libristes pensant que tous les avantages du libre sont grâce au libre) et des trackers publics.
Reste les données "sensibles" sujet au RGPD, mais il ne doit y avoir que quelques personnes dans la boite qui y a accès et si ceux-la n'ont pas la formation pour ne pas cliquer sur un lien bizarre dans un e-mail, le problème est ailleurs…
Au final, quand on prépare bien et qu'on est ouvert il reste la perte de quelques heures de travail par personne pour repartir à partir d'une machine vierge, changer sa clé SSH et ses passes partout, et c'est tout.
Par curiosité, quelles sanctions? A ma connaissance tu dois informer des données dans la nature et les sanctions sont surtout si tu n'informes pas ou que tu n'as pas eu une sécurité qui corresponde à la sensibilité (genre si tu as gardé les mots de passe en clair, ou les numéros de sécu à tous les devs "pour un jeu de test", que tout le monde a accès à la prod), pas à la fuite en elle-même.
[^] # Re: De bonnes raisons ?
Posté par flan (site web personnel) . Évalué à 4.
Il y a toujours des donnée sensibles : informations sur ton infrastructure, code spécifique (version plus complète payante, outils d’admin sys, …), fiches de salaire, base des clients et offres commerciales, nouveaux projets, stratégie pour les années à venir, …
Sans compter les conséquences pour l’image de la boîte.
Quant à résumer les attaques à de simples liens douteux… c’est bien méconnaître les attaques cybercriminelles. Un bon hameçonnage va arriver après plusieurs échanges et sera convaincant. Ou alors ton commercial n’ouvre jamais le moindre devis envoyé en PDF, mais alors j’ai un doute sur son travail.
La sanction RGPD peut tomber pour défaut de sécurisation, indépendamment de la déclaration CNIL.
[^] # Re: De bonnes raisons ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Les salariés Gitlab sont en 100% télétravail. Ils n'ont pas accès à un service informatique physique pour dépanner, ce qui implique que chacun soit suffisamment autonome avec son portable. Ça n'empêche pas d'avoir une administration distante, mais ça limite quand même (les admins sont aussi en 100% distants les uns des autres et vis-à-vis des utilisateurs, tu rajoutes pas une barrette de RAM en 5min ou remplaces un disque ssd sans l'utilisateur…).
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . Évalué à 3.
En pratique, c'est pas l'admin qui va faire ça, mais le support du fabricant. Et en général, tu ne rajoutes pas du matos aprés l'achat, tu t'arranges pour que ça soit directement fait avant la livraison.
Les revendeurs qui servent d’intermédiaire à Dell/Lenovo/etc font ça sans souci (ou peut être que c'est directement chez le fabricant).
[^] # Re: De bonnes raisons ?
Posté par claudex . Évalué à 6.
Alors, ça dépend. Ça peut être fait par les services de la boîte pour du remplacement (pas pour le setup initial). Ça évite de devoir se farcir un aller-retour chez le fabricant au moindre soucis (comme pour les serveurs physiques d'ailleurs).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: De bonnes raisons ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 7. Dernière modification le 06/08/22 à 18:54.
Le service informatique de ma boîte a déjà rajouté une barrette de RAM sur mon vénérable portable (j'ai une tendance marquée à garder le matériel longtemps). Et a changé la batterie qui avait gonflé et déformé le boîtier. Je fais le moins possible appel à eux, mais parfois c'est pratique de réparer en 10 min… Le télétravail est moins pratique pour ça.
[^] # Re: De bonnes raisons ?
Posté par Psychofox . Évalué à 6.
Je suis en télétravail et quand j'ai voulu doubler la ram de mon laptop, mon service technique m'a simplement demandé si je voulais le faire moi-même ou pas. J'ai dis oui et ils m'ont envoyé les barrettes mais sinon ils m'auraient dis d'aller chez un revendeur agréé lenovo. Ce n'est pas vraiment compliqué non.
[^] # Re: De bonnes raisons ?
Posté par Misc (site web personnel) . Évalué à 6.
Oui, quand j’étais sur ce genre de poste pendant 2 ans et demi, je l'ai déjà fait aussi parce que je sais le faire et que j'étais la. Contrairement à ce qu'on pourrais croire, les gens du support ne sont pas des monstres.
Ensuite, quand je n'étais pas la ou dans les bureaux sans service informatique sur place, ça passe par le fabriquant, ou les gens le font eux même.
Ensuite, on parle des Lenovos, qui sont facile à modifier (plus ou moins). Je pense que pour les macbooks, c'est direction le genius bar le plus proche (et ça doit être compris dans le support applecare, vu qu'une boite va payer pour ça).
[^] # Re: De bonnes raisons ?
Posté par Élafru . Évalué à 1.
Cette raison là est vraiment nulle. Si Linux devient majoritaire, tu vas faire retourner ta boîte sur Windows pour éviter le ciblage des attaquants ? Jouer à cache-cache avec les attaquants en se réfugiant dans les systèmes moins connus, c'est le meilleur moyen d'épuiser ton support informatique et de te donner une fausse sensation de sécurité.
Linux est tout à fait en mesure de fournir des environnements fortement sécurisés. Pourquoi le renier en faisant valoir à la place une analyse d'intérêts au doigt mouillé comme ça ?
# Fauxpensource et libriste en carton ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 06/08/22 à 13:24.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Zenitram (site web personnel) . Évalué à 1.
Libriste ne veut pas dire dogmatique, des fois on sait juste accepter qu'un truc ne répond pas encore au besoin en libre.
Rien de nouveau sous le soleil (coucou les dogmatique "pas de code non libre chez moi" mais qui ont leur BIOS, le truc le plus sensible en terme de sécurité, en non libre, bref des dogmatiques qui critiquent la frontière accepté par le voisin en oubliant qu'il ne fait que mettre la frontière ailleurs, le principe ne change pas entre les 2 personnes, toujours une frontière pour accepter du non libre, juste le curseur pas au même endroit).
En pratique GitLab joue le jeu de l'ouverture de leur code à fond (beaucoup de code libre, et ce qu'ils font en non libre est faisable aussi par les autres avec les mêmes règles, contrairement à ceux qui utilisent des licences libres pour s'afficher libriste mais profitent de licences qui limitent pour bloquer les autres de faire comme eux en profitant qu'ils ont des droits qu'ils ne partagent pas).
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . Évalué à -1.
Je suis pas d'accord. Le BIOS n'est pas "le plus sensible en terme de sécurité".
Deja, c'est loin d'être le plus exposé des logiciels ni le plus exploité. Il ne traite pas des données complexes venant du réseau, ses seuls inputs vont être le hardware au démarrage.
Et il suffit de remplacer "BIOS" par "grub" (qui est le suivant dans la chaine) dans la phrase pour voir que c'est totalement creux comme discours sauf dans l'esprit enfiévré d'une partie de la communauté du libre qui pense que la NSA et le Mossad s'intéresse à eux.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7.
Pas chez toi, mais dans certaines structures où on ne veut que seules les personnes dument autorisées aient accès à la machine le BIOS a son importance.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . Évalué à 3.
"pas le plus sensible", ça veut pas dire "on s'en balek".
Ça veut juste dire que dans un classement, c'est pas en haut.
La preuve, pendant des années, on a pas eu de mécanismes simples de mises à jour du BIOS ou de l'UEFI (eg, fwupdate sous Linux), et que je sache, on a pas eu d'apocalypse, et que je voudrais bien dire "le nombre de souci de sécurité lié à un souci dans le BIOS se compte sur les doigts d'une main", mais j'ai rien qui me vient à l'esprit.
À coté de ça, on a eu plus de gens qui ont eu des soucis à cause des certificats et du manque de TLS, on eu plus de souci suite à des soucis de crypto (la faille openssh de debian en 2008), etc.
Ensuite, si tu veux éviter le homebrew sur ton matériel, oui. si tu es Google, Amazon ou Nintendo ou n'importe qui qui veut controler le matériel face à ses users, oui, il te faut un BIOS blindé.
Dans une console de jeux, le BIOS va importer à mort. Mais que je sache, on parle pas de ça ici. Et non seulement on parle pas de ça, mais en plus, si on en parle, on va en parler pour la perte de liberté que ça entraîne (eg, secureboot par défaut sur les trucs ARM, etc).
[^] # Re: Fauxpensource et libriste en carton ?
Posté par FantastIX . Évalué à 5.
Ahem…
Tout le monde peut se tromper, hein.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . Évalué à 2.
Primo, c'est un rootkit UEFI. Techniquement, c'est pas du BIOS, mais je vais pas jouer sur les mots. Mais surtout, la présence d'un rootkit possible est assez séparé de la question de la sécurité.
Pour utiliser ce genre de rootkit, tu as 2 choix.
Le premier, c'est un accès physique avec assez de temps pour installer le rootkit. C'est assez spécifique, mais si tu peux reflasher la puce mémoire, alors on peut supposer que tu peux installer le rootkit en question, et c'est indépendant du code du BIOS/UEFI et de sa sensibilité vu qu'il va se faire écraser et/ou augmenter.
eg., ce qui est sensible, c'est pas le BIOS/UEFI mais la carte mère (et le fait d'accepter des BIOS/UEFI non signé, ou signé par des clés qu'on peut trouver facilement, etc)
L'autre choix, c'est de flasher depuis l'OS. La, on peut avoir une discussion sur savoir si c'est plus sur de ne pas pouvoir remplacer un logiciel (car en read-only dans une ROM) sachant que ça implique aussi de ne pas pouvoir le patcher en cas de pépin. Mais pareil, le fait de flasher ou pas n'est pas aussi important que le fait que ça implique d'avoir une faille avant pour exécuter du code ce qui rends à mon sens l'userspace plus sensible.
Si j'ai uniquement une faille userspace, je peux te voler des infos, avec ou sans faille dans le BIOS/UEFI. Si j'ai qu'une faille UEFI/BIOS, bah, je suis quand même bien coincé en tant qu'attaquant.
La, l'exemple parle d'une attaque sur le firmware, mais à part la persistance qui se fait au niveau de l'UEFI, il n'y a rien de spécial qui va montrer que l'UEFI est le plus sensible. Si je fais un implant qui persiste via cron, est ce que crond devient "le plus sensible en terme de sécurité" ?
Même si le code de l'UEFI était blindé à mort avec 5 signatures incassables et 0 failles de sécurité, ç'est un implant qui est transmis par le fabricant. Tu peux pas faire grand chose contre ça, et ça marcherais aussi bien avec un pilote d'imprimante ou n'importe quoi d'autre.
Du coup, je suis pas sur de piger exactement le point que tu cherches à démontrer par ton lacunaire Ahem.
La, par exemple, je pense que le fabricant est plus sensible en terme de sécurité que le BIOS d'une machine, surtout parce que le fabriquant s'est fait poutré et que ce genre d'attaques arrivent, alors que des attaques sur le BIOS (ou l'UEFI), y en a 0.
Et un implant, c'est pas une attaque. Pas plus que mettre un rootkit serait une attaque sur le kernel, sur une distro ou sur le projet GNU.
Mais je suis d'accord sur la 2eme partie de ton commentaire.
En effet, tout le monde peut se tromper, mais je pense tu n'avais pas besoin d'en fait la démonstration par l'exemple avec ton début de commentaire.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par FantastIX . Évalué à 4. Dernière modification le 09/09/22 à 23:42.
En effet. On ne parle plus de BIOS depuis quelque temps, terme qui est à présent remplacé par "firmware", soit [U]EFI.
Pardon? En quoi un rootkit, potentiellement ou pas, et qui, par définition, sert de porte dérobée à l'accès d'un système à l'insu de son propriétaire est "assez éloigné de la question de la sécurité"??? Franchement, je suis abasourdi par une affirmation pareille. Ou c'est moi qui pige pas ou c'est toi. Ou autre encore que je vois pas mais tu vas devoir détailler. C'est quoi "la sécurité" pour toi?
Ton argumentation est à côté de la plaque et j'ai le sentiment que tu essaies d'argumenter n'importe quoi pour t'en sortir. L'attaque UEFI permet, justement de passer sous le radar¹ et de s'installer de façon permanente, en altérant les composants qui interviennent dans le chargement de l'OS (plus particulièrement du noyau). Et, au cas où tu souhaiterais le nier, peu importe le mode d'accès utilisé par l'attaque UEFI ou le niveau de difficulté à y parvenir: dès que l'ordi est compromis, c'est mort, contrairement aux autres attaques, où une réinstallation des composants logiciels (système d'exploitation) est suffisante pour purger le système des éléments compromis. Avec une attaque UEFI, rien ne garantit qu'une réinstallation du micrologiciel soit suffisante, pour autant qu'elle soit possible. Tout dépend de son degré de sophistication.
Alors si ça n'est pas suffisamment argumenté contre l'affirmation "le
BIOSfirmware (ou micrologiciel) n'est pas le plus sensible […]" à la faveur de "le firmware est [au moins] aussi sensible que le reste", je ne sais pas ce qu'il te faux. Non, faut, pardon :-D … Parce que, tu vois, si j'étais un pirate informatique, je m'arrangerais pour développer à la [quasi] perfection ma solution d'attaque de cette section de l'ordinateur².Je ne vois pas où tu veux en venir.
Mais tu parles de quoi, au juste? Des ordinateurs "modernes" (vendus après 2000) ou bien de ces vieilleries qui tournaient avec un BIOS en mémoire EPROM? Parce que 1) on ne vend plus ces antiquités depuis lulure et 2) les dernières versions de Windows qui tournaient dessus sont Windows 7, plus vendu non plus (même si on en trouve encore). Et, par extension, qu'est-ce que t'essaies de démontrer? Que les vieux chariots ont un BIOS moins vulnérables que les nouveaux? Si c'est ça, y a pas besoin d'argumenter, c'est une porte ouverte que je me garderais bien d'enfoncer…
Ah???? T'as déjà essayé? Non, je veux dire, pour de vrai et sans partir du principe/de l'a priori que c'est mort. Parce que si oui, ça veut dire que les concepteurs de CosmicStrand (pour commencer mais il y en a d'autres, bien d'autres) ont développé une solution sophistiquée pour pas grand chose. Franchement, j'ai un doute.
Faisons un brin de logique, veux-tu: démontrer que l'affirmation "le BIOS n'est pas le composant le plus sensible" est fausse ne revient pas à démontrer que "le BIOS est le composant le plus sensible" est une affirmation vraie. S'il est aussi sensible que le reste (c'est ce que je défends comme position), alors ton affirmation est fausse, sans qu'il soit nécessaire de démontrer que "c'est le composant le plus sensible".
Garde quand même à l'esprit que si le firmware se fait plomber, le PC est bon pour le bac ou pour servir de banque de composants électroniques de réparation, façon Rossmann Group…
Rien ne démontre que l'implantation d'un malware UEFI n'est possible que chez le fabricant; les fuites de clés (privées) et l'usurpation d'identité/certificat électronique, ça existe aussi. Le cas que j'ai cité, CosmicStrand n'est qu'un exemple dont j'eus souhaité qu'il te parlât suffisamment pour éviter de raconter n'importe quoi. Je n'ai peut-être pas suffisamment insisté ou fourni de sources…
Qu'il est faux d'affirmer "le BIOS n'est pas le composant le plus sensible".
Tu te bases uniquement sur CosmicStrand, faisant par là même un biais de sélection pour ton raisonnement. Est-ce le seul malware ciblant les firmwares? Je te laisse trouver par toi-même.
Rhoooo, dis, à ce stade, c'est vraiment de la mauvaise foi, hein?
T'en as assez ou je continue³?
Qu'un implant ne soit pas une attaque (ce qui est une affirmation encore plus discutable) n'invalide en rien que ton affirmation est fausse depuis le début. Cependant, je commence à envisager que nous n’ayons pas la même définition du mot "sensible" …
C'te bonne paire. Forcément…
Raisonnement circulaire bouclé, puisque, par définition, tu estimes depuis le début que c'est moi qui me plante.
Je te propose d'en rester là, puisque nous sommes tous deux d'avis que c'est l'autre qui a tort et que rien ne semble nous faire changer de position. Alors allons nous asseoir chacun de notre côté, câliner notre chérie ou prendre un pot, c'est comme tu veux. En ce qui me concerne, en tous cas, cette discussion me fatigue.
¹ Notamment en raison de la quasi inexistence des outils de détection appropriés.
² Je te suggère, vigoureusement, de visionner les conférences Black Hat si tu ne les connais pas encore. À titre informatif, ce que j'y ai vu m'a tout simplement laissé sur le cul.
³ Ça m'a pris seulement 3 secondes sur duckduckgo.com…
[^] # Re: Fauxpensource et libriste en carton ?
Posté par octane . Évalué à 5.
ok, du coup tu dirais quoi? (puisque bon, BIOS corrompu == plein de complications pénibles à gérer ensuite)
genre iLO? (management réseau)
Le paranoïaque est il le seul à penser l'être suffisamment?
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . Évalué à 2.
Un BIOS corrompu (l'exemple du virus CIH de 1998 me vient en tête), ça serait comme du matos qui tombe en panne, sauf qu'on peut le réparer en reflashant.
Mais on peut imaginer pareil en terme de dégat sur le firmware du disque dur. En fait, c'est pire parce qu'un disque dur corrompu, ça va me coûter plus qu'un BIOS corrompu, vu que je peux changer la carte mère et voila. Sortir les données d'un disque foutu, ça coûte un chouia plus cher.
Et le firmware d'un disque, ça peut s'attaquer
C'est pas le BIOS. L'iLO tourne sur un processeur à part sur une carte à part avec un OS à part (voir quasiment un Linux embarqué).
Je veux bien qu'on compte ça dans le BIOS sous le prétexte que ça vient avec le matériel dans ton serveur, mais ça serait un abus de langage.
Ensuite, si tu parles de la fonctionnalité équivalente pour les proc intel (eg, AMT), ça vient avec le processeur, pas avec le BIOS. Encore une fois, je veux bien qu'on compte tout qui est avant grub comme "le BIOS" mais ça serait toujours un abus de langage.
Est ce que le BIOS est plus sensible que le processeur ?
Je pense que non (et c'est pour ça aussi que je dit que le BIOS n'est pas le plus sensible en terme de sécurité), mais si on dit "le BIOS est le plus sensible en terme de sécurité", alors le processeur l'est moins. Et c'est pas ce que je voit vu le foin autour des procs intels.
Ensuite, si l'affirmation est "le plus sensible en terme de sécurité, c'est le matériel", l'omniprésence de matériel et/ou de firmware non libre me laisse croire que c'est pas si sensible que ça par rapport au logiciel.
Le matos est la, il est en vente, mais pourtant, j'ai pas le sentiment que ça se bouscule pour acheter (vu qu'il n'y a que Leah sur le coup depuis des années).
Je sais pas, je suis pas psychologue, faut aller voir le DSM.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par FantastIX . Évalué à 3. Dernière modification le 10/09/22 à 14:29.
Non.
Dire qu'il "suffit" de reflasher est d'une telle incorrection que ça passe sous silence les vers suffisamment sophistiqués pouvant aller jusqu'à rendre inopérant le firmware (pour ne citer que ça). Et dans ce cas, le flashage est impossible.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Mais oui, moi aussi je suis sobre, je ne bois que de la bière.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Ysabeau (site web personnel, Mastodon) . Évalué à 1.
Tu as surtout mauvais goût, les gens normaux boivent du thé.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Il s'implique dans qbrewage (ou un truc comme ça) avec abnégation :-D
Et sinon, beaucoup préfèrent du café au thé (je suis théine aussi, mais encore mieux si je peux avoir un jus de fruit pressé, parmis ceux riche en vitamine C si c'est pour le boost)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fauxpensource et libriste en carton ?
Posté par xcomcmdr . Évalué à 9. Dernière modification le 07/08/22 à 12:28.
Ouais alors avec le Intel Management Engine (ou l'équivalent AMD), bonne chance.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fauxpensource et libriste en carton ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Avec ces saletés, il est difficile d'avoir une configuration 100% libre, mais le vrai libriste va essayer de s'en approcher.
Le faux libriste lui achète un mac et n'installe pas linux dessus.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par xcomcmdr . Évalué à 3.
C'est quoi un "vrai" libriste ?
C'est quoi un "faux" libriste ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Fauxpensource et libriste en carton ?
Posté par FantastIX . Évalué à 6.
Un vrai libriste, c'est un mec qui se fout pas mal de l'informatique, qui préfère la nature et écouter gazouiller les petits oiseaux dans le doux clapotis du ruisseau passant sous les branches du chêne centenaire.
Le faux libriste, c'est celui qui s'achète un ordinateur et en devient l'esclave.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 7. Dernière modification le 07/08/22 à 16:32.
Alors qu'une vraie libriste c'est une bibliothèque partagée avec son petit .so mignon, ses versions majeur/mineur/patch et ses liens symboliques, qui évite le DLL hell et qui est fournie empaqueté avec le système ?
Tandis qu'une FOSS libriste, c'est une extrême radicale en ouverture et liberté.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par David Demelier (site web personnel) . Évalué à 7.
J'ai un MacBook, il y a macOS dessus parce que c'est ma machine du quotidien et de MAO. Par contre j'ai un Thinkpad, un Thinkcentre et une multitude de Raspberry Pi sous OpenBSD (projet auquel je donne 10€ par mois), suis-je fiché non-libriste ?
J'espère tout de même que mes contributions à Alpine me garde toujours dans le domaine du libriste malgré ma vilaine acquisition d'un MacBook !
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Psychofox . Évalué à 9.
Je pense que tu mérites la lapidation à coups de airpods.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par David Demelier (site web personnel) . Évalué à 4.
Ça va ça fait moins mal qu'un MacPro et ses roulettes à 800 balles.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Fauxpensource et libriste en carton ?
Posté par FantastIX . Évalué à 4.
Ça dépend, genre si tu te les prends à la palette ou à la pièce…
--> []
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.