Journal Sécurité de linux

Posté par  . Licence CC By‑SA.
Étiquettes :
0
6
juin
2025

Bonjour Nal,

d'après toi, quelle serait le sujet de sécurité brûlant sur linux actuellement. Pour alimenter le débat, je me dis qu'on pourrait parler d'IOT, de défense en profondeur, de serveur web en php troués de partout, de GRsec ou de containerisation, etc…

Selon toi, si on devait s'intéresser à un aspect de la sécu sous linux (au sens large) et que d'un, lequel serait le plus important?

Merci :-)

  • # Quelle sécurité ?

    Posté par  (site web personnel) . Évalué à 10 (+9/-0). Dernière modification le 06 juin 2025 à 17:29.

    La sécurité et le réglementaire ? CRA, NIS2 ?
    La sécurité et la gouvernance ? Gestion des inventaires matériels et logiciels (SBOM)
    La sécurité et les utilisateurs ? Plein de sources différentes (paquets natifs, Flatpak, Snap, AppImage, extensions des applis, Docker, de chaque langage de programmation, les magasins d'applications, etc.) et les phishing et autres attaques de plus en plus avancées
    La sécurité et les développeurs ? Immutabilité et reproductibilité bit à bit ? Financement des composants d'infra communs ?
    La sécurité et les intégrateurs ? Les problématiques des chaînes CI/CD ?
    La sécurité et les services en ligne ? La massification des attaques par automatisation et IA ?
    La sécurité et les ops ? La configuration fine des règles de sécu avec plein de couches différentes ?
    La sécurité et les hoodies ?
    ….

  • # Sécurité brûlant

    Posté par  (site web personnel) . Évalué à 4 (+1/-0).

    Il manque un clone libre du jeu The Firemen.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # containers

    Posté par  . Évalué à 7 (+6/-0).

    La terrible habitude de beaucoup de gens de croire qu'un container, au sens namespace/seccomp/cgroup du terme, est une barrière de sécurité suffisament sûre pour faire tourner du code potentiellement dangereux dedans.

    Vivement qu'on introduise des microVMs comme primitives de premier plan pour que ces gens arrètent de se tirer une balle dans le pied.

  • # Vulnérabilité de projets cruciaux

    Posté par  . Évalué à 10 (+10/-0).

    Suite à la faille de sécurité dans xz je dirais que la priorité dans le monde du libre serait de faire une liste des "briques de base" en essayant d'estimer un ratio "difficulté de maintenance du projet"/"quantités de ressources humaines actuellement mobilisées pour le maintenir". Et dans le cas où on trouverait dans cette liste des projets nécessitant plusieurs devs à temps plein mais qui sont maintenu sur temps libre par un geek dépressif dans une cave au fin fond de l'Alaska qui n'a pas vu la lumière du jour depuis 1974, essayer d'améliorer la situation (et pourquoi pas commencer par faire un audit).

    *splash!*

  • # Le flood de bots

    Posté par  (site web personnel) . Évalué à 5 (+3/-0).

    Je ne sais pas si c'est "le plus important" mais c'est d'actualité. Le flux des bots qui ne respectent rien et qui font tomber des sites, c'est devenu un peu le gros cheval de bataille ces derniers mois. Ça s'est senti particulièrement sur les forges, et ça a donné des outils comme Anubis, mais les forges sont loin d'être les seules touchées. Quelle que soit la véritable motivation des personnes derrière ses attaques (je penche pour des crawlers codés par des IA, pour des IA, et déployés par des crétins incompétents), l'impact sur le web est celui de DDOS non ciblés et ça impacte des sites qui jusque là n'avaient pas besoin de trop se poser la question de la quantité de trafic. Il y a plein d'implications, plein de possibilités (de solution, d'explication), le sujet est riche, bref si tu as envie de faire une série sur la sécurité, cela me semble un bon candidat.

    • [^] # Re: Le flood de bots

      Posté par  (site web personnel) . Évalué à 4 (+1/-0).

      Sur les 48 derniers comptes LinuxFr, 42 n'ont pas d'IP associée (compte jamais utilisé), 1 déjà fermé pour spam, reste au mieux 5 potentiellement légitimes (dont 2 n'ayant jamais rien écrit)… le ratio est dramatiquement pas depuis peu.

  • # L'origine des composants

    Posté par  . Évalué à 3 (+1/-0). Dernière modification le 06 juin 2025 à 21:25.

    Ce n'est probablement pas un sujet excitant, mais je vois bien ces trucs, qui sont cousins, sur les "magasins de softs" :

    1. Les bibliothèques et composants de ce type (comme xz, cité par eingousef)
    2. Les repos de paquet.
    3. Les repos de bibliothèques.

    Concernant ce second point, nous avons par exemple sur une distribution classique comme Ubuntu : les repos APT officiels, les PPAs, le(s) repo snap, le(s) repo flatpak. Chaque "source" de logiciels a ses pratiques de sécurité, de mise à jour, facile/pas facile d'y entrer, etc…

    Bref, peut-on faire confiance à un flatpak, est-ce que snap c'est mieux ? Un PPA maintenu, est-ce plus secure que le paquet de la distrib qui est sur une vieille version ? Comment je mélange tout ça de manière maîtrisée ?

    Concernant le troisième point, y'a tellement de blagues… npm, pip… C'est le bordel. On pourrait aussi parler des magasins de plugin "in-app" genre pour VSCode, pour neovim, pour emacs, pour Firefox… Le moindre outil ou langage de programmation a son store, avec du sérieux et du malware mélangé.

    Autre sujet - qui fera peut-être grincer des dents certain·es libristes :

    • Vérification du code par signature électronique. On a SecureBoot pour vérifier le kernel et ses modules, on a de la cryptographie pour vérifier les paquets des repos APT. Ok mais mon AppImage Draw.io que j'ai DL de github, ou Discord que mon neveu m'a envoyé par wetransfer et que j'exécute depuis mon ~/Downloads, elle sont intègres ?

    Bref, en un mot comme en cent : dans un monde connecté dans lequel il est facile d'installer des trucs, comment savoir si c'est sûr ou non ?

    (désolé pour le côté brouillon du message)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.