AppArmor diminue-t-il les performances du système?

8

AppArmor diminue-t-il les performances du système? J'ai un système lent (CPU 900 MHz) qui a AppArmor car il a été installé par défaut je voudrais savoir s'il deviendra plus rapide si je le supprime, la sécurité est moins importante que les performances sur ce système.

Petr
la source
Probablement pas autant que certains processus détournés exécutant l'équivalent derm -rf --no-preserve-root /
jackweirdy
Mais comment un tel processus pourrait-il entrer, par exemple un système embarqué sans accès à Internet et autres? Et pourquoi diable exécuter des exécutables inconnus en tant qu'utilisateur privilégié?
Petr
Mon exemple était un peu exagéré, bien que plausible en principe. Aucun accès à Internet n'est différent, mais considérez la plupart des routeurs sans fil, commutateurs gérés et systèmes SCADA modernes - la plupart exécutent des interfaces Web pour la création de rapports et / ou la configuration. Certains permettent même aux utilisateurs authentifiés de modifier les fichiers de configuration ou d'exécuter des commandes. Imaginez si une faiblesse a été trouvée dans de telles interfaces qui permettaient aux utilisateurs non authentifiés d'exécuter des commandes (probablement en tant que root, car les appareils intégrés n'ont souvent qu'un seul utilisateur). Vous souhaitez un mécanisme pour vous assurer que les éléments cruciaux (comme / bin) ne sont pas supprimés.
jackweirdy
Si vous envisagez d'utiliser un appareil pour un appareil de très faible puissance sans aucun accès au réseau, vous pouvez être d'accord sans cela. S'il dispose d'un accès réseau, traitez-le comme s'il avait accès à Internet.
jackweirdy

Réponses:

2

Bien sûr, cela ralentit votre système. Dans quelle mesure dépend de ce que font vos applications. Les accès au système de fichiers sont plus lents (car ils doivent être vérifiés) et toutes les autres choses qui peuvent être configurées. Mais si un processus n'ouvre pas de fichiers ou de sockets, etc., il ne devrait pas être affecté du tout (après l'initialisation).

Je viens de jeter un coup d'œil à mon moteur de recherche préféré (pourquoi pas vous?) Et le résultat est que l'impact n'est pas pertinent dans la plupart des cas.

Hauke ​​Laging
la source
J'ai googlé cela moi-même, j'ai trouvé un tas de liens disant que cela ne l'affecte pas et un tas de liens disant contraire. Pas de réponse claire à ce jour ...
Petr
btw quand je google pour ça maintenant, il s'agit principalement d'un lien vers cette question, aucune idée de ce que vous avez trouvé, mais je ne trouve aucune réponse claire
Petr
@Petr Ce n'est pas une mesure indépendante, bien sûr, mais les documents de Novell disent: "Les performances ne sont pas sensiblement affectées par AppArmor." novell.com/documentation/opensuse103/opensuse103_reference/…
Hauke ​​Laging
ok donc ça vaut la peine de désactiver ou pas?
Petr
Il ne semble pas logique de désactiver AppArmor pour des raisons de performances.
Hauke ​​Laging du
1

Sauf indication contraire, devrait probablement supposer "aucun effet notable" suppose un processeur 1,8 GHz + et environ 512 Mo de mémoire ou plus. Une de mes machines est de 800 MHz, 512 Mo de mémoire. L'effet de chaque processus est perceptible. Vous seul pouvez juger si cela en vaut la peine.

DocSalvager
la source
1

Cela dépend de ce que fait votre programme: à quelle fréquence accède-t-il aux fichiers, à quelle fréquence il génère de nouveaux programmes, combien de temps il s'exécute, ... AppArmor est construit en utilisant le [LSM] 1interface, qui vérifie chaque appel système. AppArmor peut avoir un cache d'accès pour accélérer les accès récurrents aux fichiers ou les demandes ultérieures à un fichier déjà ouvert à partir du même processus, mais la surcharge la plus notable est pendant l'initialisation (un profil de programme doit être chargé et une initialisation de contexte doit avoir lieu ). Si vous êtes d'humeur à juger en quelque sorte impraticable des pires cas, voici une figure comparant AppArmor à DAC (le modèle d'autorisation traditionnel) lors d'une étude sur un autre cadre basé sur LSM (CMCAP-Linux). Le système était un Linux 4.4.6 démarré sur un Intel Core2 Duo E8400 fonctionnant à 3 GHz avec 8 Go de RAM. Le micro-benchmark consistait en 10 cycles moyens (en boucles serrées) de 10 millions d'opérations pour le test d'ouverture + fermeture, et de 10 milliers pour les 2 autres. Surcharge d'appel système: DAC vs CMCAP-Linux vs AppArmor

Butshuti
la source