cg a écrit 2180 commentaires

Il y a trois modules listés : esp4, esp6 et rxrpc.

RxRPC, je ne connais pas, mais ça semble surtout utile pour AndrewFS (AFS), un système de fichier réseau qui est, je crois, assez confidentiel.

Par contre, ESP, c'est un bout d'IPSec, qui est utilisé dans beaucoup de technos de VPN, donc probablement présent et utile dans énormément de firewalls.

Pour une machine de "particulier", ça semble sans impact de les désactiver en attendant.

Vivement un exploit dans le module ipv4 directement qu'on rigole un peu :).

Je ne me suis pas exprimé clairement, on dit la même chose :). C'était plus clair en disant : "En cartographiant le service ou le déploiement, et non l'instance particulière ?"

C'est clairement rédigé par une IA, il y a pas mal d'indicateurs qui laissent penser que c'en est une.

Oui, et là on peut se dire que c'est même une IA qui se situe entre Pangloss et Himmler :

Oui, le monde change. Resistance is futile.

(l'Histoire a prouvé que la résistance est utile)

Ce genre de futur ? Structured-Prompt-Driven Development (SPDD)

Tu cartographies le service ou le déploiement, et non l'instance particulière ?

C'est pas forcément trivial à représenter, en effet. Comment dire "ce truc est déployé via tel code (une conf Terraform par exemple), a temporairement telle forme, mais n'est pas un actif précis".

Hello,
pour ce qui concerne un cas d'usage que j'ai, l'entreprise dans laquelle je travaille fourni des ordis sous Linux aux employé·es, sans accès root. Cette faille leur permet d'obtenir un accès admin pour bricoler un peu ce qu'elles veulent dessus¹, et potentiellement faire des conneries qui auront des conséquences plus tard, ou à un bout de code récupéré sur le net d'obtenir cette accès. Donc oui c'est plutôt super grave en fait :-/.

Heureusement que c'est facile à bloquer - et c'est sans doute pour cette (mauvaise) raison que l'équipe de recherche a révélé la faille sans attendre que les distributions majeures soient prêtes.

Oui, la formation et la sensibilisation restent essentielles, mais c'est rarement suffisant.

Il y a des formations de programmation spécifiques et obligatoires sur la sécurité pendant le développement pour le shell, Go, Python (et peut-être d'autres langages) dès lors que tu interviens dans des périmètres de sécurité élevés. Ensuite, sur la base du volontariat, c'est possible de suivre ces formations aussi.

Et on a de la sensibilisation (plusieurs heures), aussi.

curl|sh

Oh, y'en a, on y pourra rien.

Pouf pouf, oui voilà. C'est une référence lointaine à ce passage :

C’est à nous, les nantis (je parle aux gens des trois premiers rangs), c’est à nous les nantis, qu’il appartient d’aider nos frères les plus démunis à s’intégrer dans nos rangs.
La coupe est pleine. Prenons-y garde, frères riches. La colère gronde au sein des masses. C’est véritablement un scandale, et probablement une contrepèterie. (Cherchez pas. Y en a pas.)

Sincèrement désolé :).

Oui, par défaut il y a 7 emplacements dans LUKS, et tu peux en avoir plus si besoin.

En l'occurrence, comme pour BitLocker sur Windows, on met une clé de récupération interminable qu'on garde au chaud en cas de besoin. Cette clé est prévue pour se taper pareil sur les dispositions qu'on offre¹ (fr, us, gb, ca, es, it, de, pt), mais pas bépo ou ergo-l, pour ne citer qu'elles. Donc dans les 0,01% de cas où on est sur un truc super exotique, on va devoir démarrer sur un système de secours ou réinstaller.

C'est sûr, plutôt que maintenir un script bash de 20 lignes qui fait une modif locale dans /etc/default/keyboard, on va faire une intégration Jira, des webhooks qui déclenchent un processus avec 200 dépendances, qui va faire des validations en interrogeant le SI, et un petit processus d'intégration continue, qui au final va avoir le droit de faire un commit dans ma base de code et envoyer tout ça en production.

Y'a des cas où c'est totalement légitime d'avoir des processus complexe, je ne dis pas ! Mais franchement, remplacer un traitement local hyper simple par un système distribué… Tu t'es un peu enflammé nan 😘 ?

Par contre oui, on utilise Puppet/OpenVox pour la maintenance des ordis, c'est super chouette.

C'est clair ! Ça resterait le plus simple et le plus convivial en terme d'usage. Voire même pourquoi pas un clavier virtuel, et une option de synthèse vocale pour l’accessibilité dès les premières étapes de démarrage. Je ne me rend pas compte de quelle masse de code ça représenterait à ajouter dans un initrd/grub.

Il y avait eu il y a quelques mois une série d'article sur les problème d'accessibilité sous Linux quand on est en mode restreint, sous le nom I Want to Love Linux. It Doesn’t Love Me Back, c'était pas mal vu.

Pour ce document spécifique, le UUoC est fortement recommandé :

cat <(curl https://www.ietf.org/archive/id/draft-meow-mrrp-00.txt)

C'est par ailleurs LE protocole de choix pour les services en .meow.

Pour mon cas, on est plutôt sur un parc géré de manière centralisée, avec Puppet qui gère le parc (on parle de 500 à 750 postes). Les installations se font de manière très automatisées. Il reste quelques manips manuelles, mais l'idée est de libérer le support informatique un maximum.

C'est bien plus simple que sous Windows, ça fonctionne bien, les utilisateurs sont contents.

Très chouette ! Est-ce que ce sont des personnes qui font un métier tech ou non ? C'est toujours intéressant d'avoir des retours de personnes qui ne sont pas spécialement férues d'ordis ou geek sur comment ça se passe pour elles.

Compare la probabilité d'être dans cette situation (qui est une erreur de configuration, que l'admin peut faire aussi si tu lui demandes de faire le changement à ta place), contre la probabilité de faire, au quotidien, une erreur parce que le caractère écrit sur la touche sur laquelle tu appuies n'est pas celui qui est "vu" par le système.

Je peux par contre imaginer que ça peut poser un problème si ton mot de passe est stocké dans une Yubikey et "tapé" par l'émulateur clavier du dit périphérique, auquel cas, peut-être que certains caractères comme les q et les a seraient inversés ? Faut que je teste ça un de ces quatre, tiens.

Par ailleurs, pour mon cas personnel, j'utilise des clavier qwerty en "us-intl alt-gr" ou "alt-weur", ça ne pose pas de problème de taper des accents.

L'un n'empêche pas l'autre, c'est complémentaire.

On fait de la défense en profondeur, pas du périmétrique (ce que je comprend par "les années 90"). On sécurise tout ce qu'on peut à plein de niveaux (on fait aussi des conneries, hein, personne n'est parfait, mais c'est l'idée).

Du moment qu'une personne peut faire un git clone ou ouvrir une documentation sur son poste, tu dois t'assurer que le poste est un minimum conforme.

Sinon il y a l'option de donner des Minitels (bureau à distance). Perso je trouve ça plus pratique de de gérer des ordis portables. Mais là encore, il faut s'assurer de toutes façons que le terminal est conforme, c'est sans fin.

Si tu as une idée précise en tête, ça m'intéresse.

Du coup c'est pas gênant qu'il y ait une différence entre dispo "système" et dispo "du bureau".

Disons que c'est acceptable, mais ça reste perfectible.

Est-ce que c'est gênant qu'il n'y ait pas de différence entre les deux dispositions ? Non, et ça semble même assez naturel sur des machines utilisées par une seule personne.
En quoi est-ce choquant de dire que c'est étrange de ne pas pouvoir choisir la disposition de clavier de démarrage ?

Par contre c'est au niveau des display manager que c'est important pour que le mot de passe de l'utilisateur soit le même qu'il le tape dans le DM ou dans le bureau/sudo.

Oui, totalement, et avoir la même chose au moment du déchiffrement LUKS, c'est un petit confort qui permet d'ajouter des manchots sur les bureaux :).

À un endroit où j'ai travaillé, on utilisait USBGuard, qui permet de limiter les périphériques à certaines classes (par exemple HID : les claviers, souris, palettes graphiques, clés de sécurité type Yubikey).

La protection physique d'un ordinateur portable, c'est assez compliqué :).

Pour rester très général, les trucs qu'on fait :

Pour ce qui est en script bash (la majorité), on utilise par défaut des options comme bash -p, et set +euf -o pipefail, qu'on désactive sur les parties qui ont besoin. Par exemple si on veut pouvoir faire un truc comme rm coincoin/*), on va faire :

set +f
rm "${dir}"/*
set -f

sans quoi l'étoile ne sera pas remplacée par une liste de fichiers.

Ensuite, on limite et on valide tous les paramètres, soit avec une liste fixe (pour les claviers, c'est une liste limitative prédéfinie), soit avec des expressions régulières. Par exemple, pour le wrapper systemctl, on autorise seulement start, stop, restart comme commandes, et on autorise pas toutes la syntaxe. Systemd permet d'avoir des \ et des . dans les noms de services. Ben nous, on ne l'autorise pas, car ça complique énormément la validation. Ça implique de devoir réfléchir à ce qu'on veut permettre, et comment ça se valide (par exemple, apt-get a beaucoup de possibilités, avec des pièges comme apt install lolcat -puppet qui supprime puppet, il faut le détecter, c'est expliqué dans l'article comment on fait).

Quand on peut, on a donc une liste autorisée, mais parfois ce n'est pas possible. On fait alors une liste de trucs interdits. Par exemple, avec systemctl, il y a des services qui sont "protégés" et ne peuvent pas être coupés. cron, puppet, l'antivirus… Ce genre de choses importantes.

Comme les scripts tournent en root via sudo, quand on doit lancer une sous-commande, si possible on la lance avec nobody si ce sont des droits suffisants. Par exemple, pour résoudre les alias de services systemd, on lance systemctl show -P Names en noboby depuis le wrapper.

Et puis on teste, on essaye de contourner les bridages qu'on met en place… Et des fois on trouve, c'est amusant :). Exemple simple : sur le wrapper de nmcli, on avait naïvement bloqué les paramètres -s et --show-secrets. Mais on pouvait le contourner avec --show-se par exemple, car nmcli sait deviner que c'est --show-secrets qu'on voulait dire.

Les configs sudo ne vont pas dire :

(ALL: ALL) le_wrapper
(ALL: ALL) le_wrapper *

mais plutôt quelque chose comme :

(ALL: ALL) le_wrapper start *
(ALL: ALL) le_wrapper stop *
(ALL: ALL) le_wrapper restart *
(ALL: ALL) le_wrapper --help


pour filtrer un peu avant que l'exécution commence.

Ah et bien sûr l'option NOPASSWORD de sudo est interdite ;).

Enfin, on passe des outils comme shellcheck, qui donnent des conseils utiles, comme mettre en guillemets les paramètres qui peuvent contenir des étoiles (ça arrive qu'on oublie de le faire).

Finalement, le truc sur lequel perso je vais le plus attention, c'est la validation des paramètres.

Ben en fait ça parait une super idée jusqu'au jour où ledit utilisateur à changé la conf globale et bloque l'accès à la machine et appel le support technique.

C'est tout l'objet d'avoir ces outils : permettre d'une part de limiter les options, pour autonomiser sans trop de risque, et pour éviter de recourir au support technique pour des choses simples.

C'est arrivé qu'une personne casse son système en supprimant python par exemple.

Mais c'est aussi arrivé que le support technique fasse une faute de frappe subtile dans un fichier de conf, et casse partiellement le système.

Donc pour les trucs récurrents, on offre un outil qui limite les paramètres, ce qui limite les erreurs humaines.

Généralement la disposition est choisie à l'installation et correspond à la machine

Vrai

et n'a pas besoin d'être changée

Faux :)

Oui, l'exemple de Grub n'est pas très bien choisi :). Celui de LUKS reste pertinent.
Un autre exemple, c'est si tu dois te connecter depuis une console texte (parce que Xorg/Wayland sont cassés), pouvoir taper son login/mot de passe avec la disposition dont on a l'habitude apporte un confort. Tu pourras dire que ce n'est pas pour tout le monde non plus, mais ne pas avoir à se battre avec son clavier en cas de panique, surtout pour une personne peu habituée à la console ("les masses"), ça me semble pas trop déconnant :).

Allez, je donne un indice : Pierre Desprogres.

Salut,
oui, je sais bien la raison : un système Linux est multi-utilisateurs par défaut, il pouvoir en effet changer globalement peut amener au problème que tu cites.

Mais là, on est sur des postes de travail individuels, et à ma connaissance, il n'existe pas de moyen de dire à la distrib (ici, Ubuntu) : c'est une machine qui est mono-utilisateurice, donc certains réglages personnels s'appliquent à tout le systeme, sans, dans le même temps, donner l'accès admin.

C'est un petit détail, mais au moment du démarrage, on a besoin de taper une mot de passe pour déverrouiller le container LUKS qui contient les partitions, et c'est avant d'être dans la session personnelle, donc avant de savoir quelle disposition de clavier doit être utilisée. Pareil pour si tu dois taper le mot de passe de Grub. (perso je contourne ça en choisissant des phrases de passe qui se tapent pareil en azerty et qwerty, mais ce n'est pas toujours possible, par exemple si on doit mettre un chiffre).

Ça semble un peu niche, mais la critique que j'adresse, c'est que des trucs qui semblent un peu simples, sur une machine Linux sur laquelle on est pas admin, ben c'est pas forcément prévu. Je ne dis pas qu'il y a une solution simple à ça, et c'est bien pour cela qu'on fait des outils dédiés…

On a l'avantage de n'avoir quasiment que des personnes qui savent se servir d'un terminal, et que ça ne choque pas de devoir taper une commande. Mais je pense surtout qu'il y a moyen de faire mieux, plus intégré, pour le cas d'un système personnel. Si on regarde les systèmes comme les téléphones, on peut changer la langue de démarrage sans être "admin" de l'appareil pour autant.

Le court article Why is IPv6 so complicated? propose une rétrospective et une argumentation de pourquoi il était inévitable[^1] que la transition d'IPv4 à IPv6 soit aussi longue.

Il y a un chouette tableau au milieu :

To state this in graphical form, here's a diagram, showing who can talk to who, assuming the simplistic model of IPng with 64 bit addresses:

              OLD    DUAL   NEW     
            ----------------------
        OLD |  32  |  32  |  XX  |      
            |------|------|------|
       DUAL |  32  |  64  |  64  |
            |------|------|------|
        NEW |  XX  |  64  |  64  |
            ----------------------

Il y a quelques années, Facebook, Instagram, et WhatsApp sont tombés en panne. Mais la source du problème était niveau réseau (lié à BGP je crois), ce qui avait aussi fait planter ses systèmes de contrôle d'accès… Les employés ne pouvaient pas entrer dans les locaux pour dépanner.

Bien vu !

En tout cas, depuis leur site, qui est motorisé par des logiciels libres, j'avais pu m'abonner et je reçois les exemplaires papier chez moi :p.