Re: Debian security
Philippe Strauss via gull <gull-04vmY7CpswVinyhjFObuvR+/[email protected]> Thu, 05 Sep 2024 09:52:53 +0200
| Newsgroups | gmane.org.user-groups.gull.general |
|---|---|
| Message-ID | <[email protected]> |
En préparation dans les versions de dév. du noyau il y a landlock, un modèle de LSM (linux security module) dans lequelle ce n'est plus au sysadmin d'établir les règles pour un logiciel (service) mais le développeur de l'applicatif. Un bon choix, c'est le développeur qui sait le mieux ce que son service fait comme interaction valide, normale, avec le système. https://docs.kernel.org/userspace-api/landlock.html a+ On Thu, Sep 5 2024 at 08:33:40 AM +02:00:00, Marc SCHAEFER via gull <[email protected]> wrote: > Salut, > > On Wed, Sep 04, 2024 at 07:06:25PM +0200, Claude Paroz via gull wrote: >> Ça sent le FUD à plein nez. Et comme tout FUD, il y a très >> probablement >> quelques vérités à l'intérieur. > > Certainement. Je pense que le monde a bien changé, et que la > complexité des attaques ne fait qu'augmenter. Le modèle de Debian > doit évoluer, bien entendu. > > Mais il évolue: l'auteur de ce billet mentionne le fait que Debian > a mis en place des politiques par défaut depuis quelques versions, > par exemple. Pour être clair, sur ma prod lxc, je me rappelle avoir > bien dû me battre avec app-armor vers 2010 quand j'avais migré à > la version de Debian d'alors: certaines règles étaient trop > strictes. Dans certains cas, c'était un problème de design, > que j'ai corrigé dans le code virtualisé, mais il y avait aussi > des cas où cela ne faisait pas sens. > > > La grande question que je me pose en ce moment c'est même pas sur les > distributions, c'est plus général: à terme, aura-t-on les > ressources en > tant que sysadm de gérer tout ça? Ou sera-t-on condamné à passer > par un > opérateur de cloud, qui seul sera capable de faire face aux menaces > (attaques ciblées) ? > > > Sur le fond du billet , j'ai juste voulu vérifier UN élément, le > fait > qu'on puisse faire par défaut n'importe quel appel réseau dans un > conteneur sans restriction (sur ma prod, sans ajouter des > capabilities à la main, impossible p.ex. de mettre > OpenVPN dans un conteneur -- mais bien sûr il ne fait pas que > des choses simples réseau, il crée aussi des interfaces). > > Voici un conteneur sur une infra de test de oldstable (Debian 11, la > seule version actuellement LTS) installée par défaut, sans aucune > configuration spécifique app-armor: > > root@ds-demo-fail2ban:~# ip address add 192.168.103.199/32 dev eth0 > RTNETLINK answers: Operation not permitted > > (de toute façon, cela ne servirait à rien en prod: l'architecture > réseau empêche le spoofing) > > Alors, il ne parle peut-être pas de ça, mais il semble quand même > que > son jugement est à l'emporte-pièce sur CE détail, au minimum. > _______________________________________________ > gull mailing list > [email protected] > https://forum.linux-gull.ch/mailman/listinfo/gull _______________________________________________ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull