Posté par Big Pete .
Évalué à 5 (+3/-0).
Dernière modification le 23 juillet 2024 à 16:06.
C'est pour la sécurité du systéme. cette application est sensé contrôlé, justement, que rien ne vient se mettre dans cet espace pour mettre le bazar.
Pour faire une analogie (pétée, évidement) d'actualité, c'est comme embaucher un garde du corps dans le privé pour protéger le président mais dont les compétences sont discutable et qui se loupe en rechargeant son flingue et butte le président.
Ensuite, il est évidement de bon ton pour les services de protection du président d'accuser le gouvernement d'avoir ouvert le marché de la protection des personnalités, évidement.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
Bah, les anty-cheat sont des applications d'éditeur tiers qui tourne dans des espaces noyaux.
La virtualisation a des besoins d'accès à l'espace noyaux.
Les drivers pour du matériel d'éditeur peu connu, peuvent avoir des applications d'éditeur tiers qui tourne dans l'espace noyaux.
Je ne comprends pas, comment tu ne comprends pas qu'un éditeur tiers à besoins d'accès a l'espace noyaux.
Un anti virus (ou de manière plus globale) une solution de sécurité complète ne fait pas que de lire des fichiers pour trouver des fichiers suspects à partir d'une empreinte.
Tu as aussi l'analyse du trafic réseau pour détecter des comportements suspects, refuser des paquets selon des critères propres, analyser les droits d'accès des fichiers de manière plus fines ou strictes que ce que l'OS propose par défaut, etc.
Des choses qui se font massivement sous Linux avec accès au noyau par des composants externes.
Idéalement ces accès devraient passer par une API pour limiter les possibilités de crash du genre (comme eBPF propose par exemple).
Un anti virus (ou de manière plus globale) une solution de sécurité complète ne fait pas que de lire des fichiers pour trouver des fichiers suspects à partir d'une empreinte.
= un anti virus, contrairement à son nom, ne se contente pas de détecter un fichier vérolé…
Tu as aussi l'analyse du trafic réseau pour détecter des comportements suspects, refuser des paquets selon des critères propres,
= ça fait aussi un genre de pare-feux
(pour les usagers de Fenêtre, d’une certaine époque, votre Avast doit se confondre avec votre ZoneAlarm…)
analyser les droits d'accès des fichiers de manière plus fines ou strictes que ce que l'OS propose par défaut, etc.
= ça va remplacer le système d’exploitation à la ramasse de façon peu transparente
(pour les usagers du bison/manchot, je suppose que l'anti-virus décrit ici doit remplacer AppArmor ou SELinux etc.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je rajouterais à la réponse de Renault, que le module kernel peu aussi servir à injecter des portes à détecter si on n'a pas de modules malicieux qui tourne dans le pays du noyau (oui, j'ai traduit kernel land).
Bon pour les anty-virus ça peut être compliqué (vu que je suppose que si on a un module malicieux, il est obstrué), mais pour les anty-cheat les cheat sont souvent codés en tant que module kernel.
Posté par flagos .
Évalué à 10 (+12/-0).
Dernière modification le 23 juillet 2024 à 15:58.
J'avais bossé pour une solution de monitoring basé sur un module driver dans Windows.
Il avait fallu implémenter a la mano un système pour l'auto débrayer si le logiciel plantait. Le logiciel comptait le nombre de BSOD (je me souviens plus si on pouvait savoir si le crash venait du driver ou non) et au bout de 3 bsod le logiciel se desactivait.
Et un jour, ce qui devait arrivait arriva: mise a jour d'un contenu sur windows avec un char a la con => crash du module sur des millions de devices en quasi simultané. Et au bout de 3 fois le soft s'est désactivé, aucun des utilisateurs n'a ete bloqué. La boîte n'a meme pas eu de bad buzz et on a pu livrer le fix relativement tranquillement, en une journée quoi.
Bref, dans tout ce que j'ai entendu, ce qui m'a le plus choqué c'est pas tant les mises a jour automatique en production ou autres pratiques sysadmin, c'est plus que ni CrowdStrike, ni Microsoft n'ait implémenté un mécanisme similaire.
Posté par Psychofox (Mastodon) .
Évalué à 7 (+4/-0).
Dernière modification le 23 juillet 2024 à 16:33.
…c'est que l'europe a probablement été bien moins touchée par le bug qu'en Amérique du Nord parce que Crowdstrike est moins populaire en entrprise ici. Moi perso je n'en ai entendu parler que via les news, le travail et fediverse. Localement, les banques, les commerces et l'impact sur l'aéroport a été limité.
# Espace kernel ?
Posté par ash . Évalué à 2 (+1/-0).
J'ai du mal à comprendre ce que vient foutre une application d'un éditeur tiers en espace noyau ?
[^] # Re: Espace kernel ?
Posté par Big Pete . Évalué à 5 (+3/-0). Dernière modification le 23 juillet 2024 à 16:06.
C'est pour la sécurité du systéme. cette application est sensé contrôlé, justement, que rien ne vient se mettre dans cet espace pour mettre le bazar.
Pour faire une analogie (pétée, évidement) d'actualité, c'est comme embaucher un garde du corps dans le privé pour protéger le président mais dont les compétences sont discutable et qui se loupe en rechargeant son flingue et butte le président.
Ensuite, il est évidement de bon ton pour les services de protection du président d'accuser le gouvernement d'avoir ouvert le marché de la protection des personnalités, évidement.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Espace kernel ?
Posté par jtremesay (site web personnel) . Évalué à 7 (+6/-1).
Grave. T’imagines si la NSA faisait "un module de sécurité" à faire tourner dans notre noyal préféré ? #ohwait
[^] # Re: Espace kernel ?
Posté par uso (site web personnel) . Évalué à 1 (+0/-0).
Bah, les anty-cheat sont des applications d'éditeur tiers qui tourne dans des espaces noyaux.
La virtualisation a des besoins d'accès à l'espace noyaux.
Les drivers pour du matériel d'éditeur peu connu, peuvent avoir des applications d'éditeur tiers qui tourne dans l'espace noyaux.
Je ne comprends pas, comment tu ne comprends pas qu'un éditeur tiers à besoins d'accès a l'espace noyaux.
[^] # Re: Espace kernel ?
Posté par ash . Évalué à 1 (+0/-0).
La virtualisation et les drivers ont besoin d'accéder au matériel donc ça me parait justifié. Mais un anti-virus ? lol.
[^] # Re: Espace kernel ?
Posté par Renault (site web personnel) . Évalué à 3 (+0/-0).
Pourquoi "lol" ?
Un anti virus (ou de manière plus globale) une solution de sécurité complète ne fait pas que de lire des fichiers pour trouver des fichiers suspects à partir d'une empreinte.
Tu as aussi l'analyse du trafic réseau pour détecter des comportements suspects, refuser des paquets selon des critères propres, analyser les droits d'accès des fichiers de manière plus fines ou strictes que ce que l'OS propose par défaut, etc.
Des choses qui se font massivement sous Linux avec accès au noyau par des composants externes.
Idéalement ces accès devraient passer par une API pour limiter les possibilités de crash du genre (comme eBPF propose par exemple).
[^] # Re: Espace kernel ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+2/-1).
Puis-je me permettre de traduire ?
= un anti virus, contrairement à son nom, ne se contente pas de détecter un fichier vérolé…
= ça fait aussi un genre de pare-feux
(pour les usagers de Fenêtre, d’une certaine époque, votre Avast doit se confondre avec votre ZoneAlarm…)
= ça va remplacer le système d’exploitation à la ramasse de façon peu transparente
(pour les usagers du bison/manchot, je suppose que l'anti-virus décrit ici doit remplacer AppArmor ou SELinux etc.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Espace kernel ?
Posté par uso (site web personnel) . Évalué à 1 (+0/-0).
Je rajouterais à la réponse de Renault, que le module kernel peu aussi servir à
injecter des portesà détecter si on n'a pas de modules malicieux qui tourne dans le pays du noyau (oui, j'ai traduit kernel land).Bon pour les anty-virus ça peut être compliqué (vu que je suppose que si on a un module malicieux, il est obstrué), mais pour les anty-cheat les cheat sont souvent codés en tant que module kernel.
# Auto désactivation
Posté par flagos . Évalué à 10 (+12/-0). Dernière modification le 23 juillet 2024 à 15:58.
J'avais bossé pour une solution de monitoring basé sur un module driver dans Windows.
Il avait fallu implémenter a la mano un système pour l'auto débrayer si le logiciel plantait. Le logiciel comptait le nombre de BSOD (je me souviens plus si on pouvait savoir si le crash venait du driver ou non) et au bout de 3 bsod le logiciel se desactivait.
Et un jour, ce qui devait arrivait arriva: mise a jour d'un contenu sur windows avec un char a la con => crash du module sur des millions de devices en quasi simultané. Et au bout de 3 fois le soft s'est désactivé, aucun des utilisateurs n'a ete bloqué. La boîte n'a meme pas eu de bad buzz et on a pu livrer le fix relativement tranquillement, en une journée quoi.
Bref, dans tout ce que j'ai entendu, ce qui m'a le plus choqué c'est pas tant les mises a jour automatique en production ou autres pratiques sysadmin, c'est plus que ni CrowdStrike, ni Microsoft n'ait implémenté un mécanisme similaire.
# L'ironie...
Posté par Psychofox (Mastodon) . Évalué à 7 (+4/-0). Dernière modification le 23 juillet 2024 à 16:33.
…c'est que l'europe a probablement été bien moins touchée par le bug qu'en Amérique du Nord parce que Crowdstrike est moins populaire en entrprise ici. Moi perso je n'en ai entendu parler que via les news, le travail et fediverse. Localement, les banques, les commerces et l'impact sur l'aéroport a été limité.
# intéressant
Posté par antistress (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 23 juillet 2024 à 17:12.
Intéressant le dernier paragraphe, une sortie de Linus sur la question ne me surprendrait pas
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.