Vous pouvez installer un antivirus si vous le souhaitez. Cela ne devrait pas nuire à votre machine, mais ne vous attendez pas à beaucoup de protection pour votre système et ne vous considérez pas comme entièrement sûr . L'efficacité des logiciels antivirus est très relative et ils sont principalement utilisés pour éviter de propager d'anciens logiciels malveillants, en particulier si vous avez des machines Windows dans votre écosystème. Vous devez vous attendre à une diminution des performances, bien qu'il n'y ait pas de référence des performances audiovisuelles sous Linux à ce jour, donc cela ne peut pas être quantifié.
Pourquoi vous n'êtes pas en sécurité avec juste un antivirus? Parce qu'ils ne sont qu'une partie des mécanismes nécessaires. Pour le moment, il manque beaucoup d'outils pour la sécurité des postes de travail sous Linux. Quels sont les différents mécanismes de sécurité applicables aux ordinateurs de bureau?
- Sécurité de la pile graphique (pour empêcher les keyloggers, le détournement de clics, l'enregistrement d'écran, le reniflement du presse-papiers, etc.)
- Schémas de distribution d'applications avec contrôles de sécurité (magasins d'applications et référentiels avec analyse statique des applications) et mises à jour de sécurité rapides
- Détection des logiciels malveillants : signature- basé (pour se protéger des menaces identifiées) et basé sur l'heuristique (du moins c'est ce qu'on dit, je n'ai jamais utilisé de logiciel antivirus basé sur l'heuristique et je soupçonne qu'il s'agit principalement d'un discours marketing pour dire "nous allons vous lancer des tonnes d'avertissements de sécurité lorsque vous utilisez une nouvelle application ")
- Sandboxing (qui consiste à isoler les applications les unes des autres par conception)
- Autorisation contextuelle d'utiliser des appareils et données utilisateur avec sécurité par désignation / contrôle d'accès piloté par l'utilisateur / powerbox / contrats; nécessite le sandboxing
Actuellement, la seule chose décente sous Linux est les mises à jour de sécurité de l'application, via des référentiels. Tout le reste est de mauvaise qualité.
Sécurité de la pile graphique
Nous comptons tous sur le serveur graphique X11. X.Org existe depuis 30 ans et la conception originale est toujours utilisée sur le serveur. À l'époque, il n'y avait pas de problèmes de sécurité sur le bureau et vous ne serez pas surpris d'apprendre qu'il n'est pas du tout sécurisé. Vous avez des API prêtes à l'emploi pour implémenter des enregistreurs de frappe, faire des exploitations de code à distance si l'utilisateur a une console racine ouverte, remplacer le casier de session pour voler des mots de passe, etc.
Il est difficile d'évaluer comment Windows 8 et OS X tarif sur ce sujet car je n'ai pas pu trouver d'explications détaillées sur leur implémentation de pile graphique. Leurs applications en bac à sable ont un accès limité aux vecteurs d'attaque les plus évidents, mais on ne sait vraiment pas à quel point tout cela est bien conçu et mis en œuvre. Il me semble que Win 8 oblige les applications Store à s'exécuter en plein écran et une à la fois masque les problèmes de conception d'un gestionnaire de fenêtres sécurisé à grande échelle. Il y a beaucoup de problèmes à prendre en compte. la position et le dimensionnement de la fenêtre, l'utilisation de la transparence et du plein écran, etc. lors de la mise en œuvre d'un gestionnaire de fenêtres avec la sécurité à l'esprit. Je n'ai aucune idée de comment fonctionne OS X.
Linux passera à Wayland dans les années à venir, qui est conçu avec la sécurité à l'esprit. Nous avons un modèle clair des capacités qui devraient exister et une idée générale de la manière dont elles seront appliquées et de la manière dont l'autorisation peut être obtenue. La personne principale derrière ce travail est Martin Peres, bien que je sois impliqué dans la discussion de l'expérience utilisateur et développeur derrière les fonctionnalités. La conception et le développement sont en cours, alors ne vous attendez à rien de si tôt. Lisez ce message pour plus d'informations. Wayland assurera la sécurité de manière transparente lorsqu'il est utilisé en conjonction avec le sandboxing des applications.
Distribution d'applications
Linux dispose d'un système de référentiels avec différents niveaux de confiance, qui a formé nos utilisateurs à ne compter que sur les applications et se méfier du code propriétaire. C'est très bon en théorie.
Dans la pratique Je ne connais pas un seul distributeur qui applique les contrôles de sécurité les plus élémentaires sur leurs applications packagées . Aucune analyse statique pour les appels système étranges, et pour toute communauté, il n'est vraiment pas clair si les scripts pré et post-installation (qui s'exécutent en tant que root) sont vérifiés pour de mauvaises choses évidentes.
Les contrôles de sécurité fait sur les extensions de GNOME Shell sont très légères et manuelles, mais au moins existent. Je ne connais pas les extensions de KDE ou d'autres applications.
Un domaine dans lequel nous brillons est que nous pouvons extraire des mises à jour de sécurité très rapidement, généralement en quelques jours pour toute faille de sécurité. Jusqu'à récemment, Microsoft était beaucoup plus lent que cela, bien qu'ils aient rattrapé leur retard.
Détection des logiciels malveillants
Le seul logiciel antivirus que je connaisse sous Linux est ClamAV. Il me semble que cela ne fonctionne que sur la base de signatures, mais là encore, comme vous l'avez souligné, nous n'avons aucun malware de bureau identifié contre lequel nous protéger.
Il y a probablement des gens qui écrivent un bureau Linux les logiciels malveillants dans le monde des menaces persistantes avancées. Voir Masque pour un exemple. Il est peu probable que l'AV standard puisse faire quoi que ce soit contre ceux-ci, car les auteurs de logiciels malveillants APT sont généralement assez talentueux pour proposer des exploits zero-day.
Maintenant, Microsoft annonce des tests fuzz sur tous ses logiciels pour des dizaines de milliers de heures, par opposition à pratiquement aucune pratique de codage sécurisé dans l'écosystème Linux. D'après des expériences personnelles avec le fuzzing, je suis absolument convaincu qu ' il existe une poignée d'exploits zero-day faciles à manipuler dans certains logiciels Linux populaires . Cela viendra nous frapper le jour où nous aurons une base d'utilisateurs financièrement viable pour les auteurs de logiciels malveillants courants, puis nous verrons à quel point ClamAV se révèle être bon, mais je soupçonne que le mécanisme de mise à jour de l'application aura un impact plus important sur le traitement. avec des vulnérabilités découvertes.
Inutile de dire que Windows et OS X font beaucoup mieux que Linux sur ce critère.
Sandboxing et autorisation contextuelle
OS X et Windows 8 fournissent le sandboxing pour les applications hébergées sur leur boutique. Je n'ai pas fini de me pencher sur les bizarreries d'OS X, mais les applications Windows 8 Store ont de très sérieuses limitations en termes de langues et d'API prises en charge, de fonctionnalités disponibles et d'expérience utilisateur générale qui peuvent être fournies avec elles. Cela signifie que les applications de bureau sans bac à sable sont là pour rester et que le bac à sable de Microsoft ne protégera pas contre les logiciels malveillants, mais uniquement contre les documents conçus dans un logiciel bogué (Store App). OS X semble faire beaucoup mieux, même si toute application non destinée au magasin n'est pas non plus mise en bac à sable.
Linux n'a pas de bac à sable d'application graphique fonctionnant de manière suffisamment transparente pour le moment. la technologie de confinement sous-jacente (les meilleurs candidats étant des conteneurs basés sur des espaces de noms Linux, voir LXC et Docker), et les systèmes d'application MAC qui devraient être développés à côté des meilleurs pour supporter une certaine dynamicité). Nous avons presque les mécanismes IPC et de gestion des processus nécessaires pour déployer et gérer ces applications en bac à sable grâce à un travail incroyable sur kdbus et systemd. Il manque quelques éléments, avec quelques propositions poussées principalement par la Fondation GNOME (voir cette vidéo sur Sandboxing à GUADEC 13). Je suis également impliqué dans la discussion sur la façon dont l'accès aux données et l'autorisation peuvent se produire, mais il n'y a pas de consensus entre les quelques personnes intéressées, et la conception et le développement prennent du temps. Il faudra probablement encore quelques années avant que des prototypes décents n'existent et avant que le sandboxing ne soit déployé sur Linux à n'importe quelle échelle pertinente.
L'un des grands problèmes rencontrés sur toutes les plates-formes est de savoir comment autoriser les applications à accéder aux données et aux capacités des appareils à la bonne échelle. Cela signifie comment les laisser faire ce dont ils ont besoin sans harceler les utilisateurs avec des invites d'autorisation tout en empêchant les applications d'abuser des privilèges. Il existe de sérieuses lacunes dans la manière dont Windows 8 permet aux applications Store de gérer les documents et les applications récents futureAccessList. À ce stade, sécuriser davantage l'accès aux documents sans aggraver le coût de la sécurité pour les développeurs et les utilisateurs est une question ouverte, sur laquelle de nombreuses personnes travaillent également :)