Sécurité / Contrôle d'accès obligatoire

AppArmor

Confinement applicatif AppArmor sur Arch Linux: activation LSM, profils enforce/complain, logs, stratégie de déploiement et dépannage.

AppArmor MAC LSM aa-status aa-logprof

Position AppArmor dans la défense en profondeur — Vue publique: LSM kernel, profils AppArmor, modes enforce/complain, journaux AVC et ajustement progressif.

Activer

Charger AppArmor via la pile LSM et démarrer le service systemd.

Classer

Séparer services système matures, applications desktop complexes et profils expérimentaux.

Appliquer

Mettre en enforce les profils stables et en complain les profils à observer.

Ajuster

Lire les logs, utiliser aa-logprof et documenter chaque exception.

Contexte

Le problème réel.

Les permissions Unix classiques ne suffisent pas si un service ou une application est compromis. AppArmor ajoute des règles obligatoires pour limiter ce qu'un processus peut lire, écrire ou exécuter, même avec des privilèges élevés.

Objectifs

Ce que la solution devait garantir.

Limiter l'impact d'une compromission de service ou d'application.
Activer AppArmor proprement via les paramètres kernel.
Déployer les profils progressivement sans casser l'usage desktop.
Relier les changements AppArmor aux journaux auditd/SecOps.

Architecture publique

Structure documentée, détails exploitables retirés.

MAC kernel. AppArmor restreint les accès selon des profils, même quand le processus a des privilèges élevés.
Profils. Les profils basés sur chemins définissent fichiers, capacités, exécutions et abstractions autorisées.
Modes. Enforce bloque et log, complain observe sans bloquer pour préparer l'ajustement.
Audit. Les refus et changements de politique sont lus via journaux kernel, aa-logprof et auditd.

Exemples anonymisés

Ce qui peut être montré sans exposer le système réel.

Matrice AppArmor

Exemple basé sur la stratégie documentée: services en enforce, applications desktop complexes en complain.

type de cible          contrôle            mode documenté
service critique       AppArmor           enforce
navigateur desktop     sandbox natif      isolation testée en plus
app desktop complexe   AppArmor           complain d'abord
IDE / outils dev       exception          documentée et surveillée

Profil simplifié non exploitable

La documentation privée contient des exemples AppArmor; la version publique garde seulement l'intention.

autoriser la lecture des fichiers runtime requis par le rôle
autoriser l'écriture dans une zone de cache dédiée
refuser la lecture des magasins d'identifiants
refuser l'écriture de la configuration système
refuser les capacités d'administration larges
autoriser le réseau seulement si le rôle l'exige

Cycle de déploiement

La méthode privilégie le test progressif pour éviter une sécurité désactivée au quotidien.

observer -> complain -> ajuster -> enforce -> surveiller les refus -> documenter l'exception

Runbook public

Commandes et états attendus issus de la documentation privée.

Les commandes ci-dessous sont volontairement anonymisées: chemins, noms de machines, interfaces, dépôts, périphériques et actions destructrices sont remplacés par des placeholders.

Documentation privée: apparmor

État AppArmor

Commandes anonymisées

aa-status
cat /sys/kernel/security/lsm
ausearch -m AVC -ts recent
journalctl -k --since '1 hour ago' | rg 'apparmor.*DENIED'

État attendu

le module AppArmor est actif
validation observée: 175 profils chargés
119 profiles in enforce
7 profiles in complain
0 refus AVC récents sur la fenêtre de validation

Documentation privée: apparmor

Déploiement progressif

Commandes anonymisées

aa-status | rg 'enforce|complain'
aa-complain <profile-under-test>
<exercise-application-normally>
journalctl -k | rg 'apparmor'
aa-logprof

État attendu

les services aux profils mûrs passent en enforce
les applications desktop complexes commencent en complain
les logs sont relus avant durcissement
les exceptions sont documentées au lieu de désactiver silencieusement le confinement

Documentation privée: apparmor

Gestion des profils

Commandes anonymisées

aa-status
aa-enforce <profile-path>
aa-complain <profile-path>
aa-disable <profile-path>
apparmor_parser -r <profile-path>
systemctl reload apparmor.service

État attendu

le mode du profil est explicite
enforce est réservé aux profils testés
complain sert à l'apprentissage et à la validation desktop
les profils désactivés sont documentés
le reload applique les changements sans masquer les logs

Travail réalisé

Décisions techniques publiables.

Activation

La page documente l'ajout AppArmor dans la pile LSM et la vérification après reboot.

Stratégie

Services système en enforce, applications desktop complexes en complain au départ.

Profils

Gestion avec aa-enforce, aa-complain, aa-disable, apparmor_parser et reload du service.

Logs

Analyse des DENIED/ALLOWED, aa-logprof et vérification des AVC récents.

Validation

Preuves et contrôles retenus.

Vérification du statut AppArmor et des profils actifs.
Test d'usage réel avant d'augmenter le niveau de confinement.
Lecture des refus récents pour distinguer blocage utile et profil incomplet.
Retour possible en mode observation pendant l'ajustement.

Preuves visuelles

Contrôles observables et portée de la preuve.

**État nominal AppArmor.** La capture montre le module chargé, les profils AppArmor actifs, la répartition enforce/complain et l'absence de refus récents sur la fenêtre de validation.

Résultats publics

Ce que le chantier démontre.

Page AppArmor dédiée, séparée de Firejail.
Stratégie enforce/complain lisible.
État validé Morpheus documenté sans logs bruts.
Méthode d'ajustement exploitable sans publier de profils privés.

Anonymisation

Ce qui reste privé.

Pas de profils complets.
Pas de noms de fichiers personnels.
Pas de journal de refus brut.
Les matrices publiées restent génériques et non exploitables.

Sources privées

Documentation d'origine.

Documentation AppArmor.
Hardening système.
Journal d'audit des permissions et services.
Auditd et suivi des changements de politique.

Supplément de documentation privée anonymisé

AppArmor - Confinement applicatif sur Arch Linux

Guide public pour mettre en place AppArmor, un système de contrôle d'accès obligatoire. Les profils privés, chemins locaux et journaux bruts sont remplacés par des placeholders.

Qu'est-ce qu'AppArmor ?

AppArmor limite les accès d'une application aux ressources système selon un profil. Contrairement aux permissions classiques DAC, le MAC impose des règles que le processus ne peut pas contourner simplement parce qu'il dispose de privilèges élevés.

Aspect	AppArmor	SELinux
Modèle	Profils basés sur chemins	Labels
Complexité	Modérée	Élevée
Maintenabilité desktop	Bonne	Plus exigeante

Objectif

Restreindre les actions des applications et services.
Limiter l'impact d'une compromission.
Renforcer la défense en profondeur.
Conserver une expérience desktop fluide.

Contexte

Poste Arch Linux personnel avec pile LSM déjà documentée dans le hardening kernel. AppArmor est traité comme couche MAC, complémentaire à nftables, Firejail, systemd et auditd.

Installation

pacman -S apparmor
pacman -S apparmor-profiles
pacman -S apparmor-utils
ls <APPARMOR_PROFILE_DIR>
systemctl status apparmor.service

Activation

AppArmor doit être présent dans la ligne de commande kernel:

lsm=landlock,lockdown,yama,apparmor,bpf apparmor=1 security=apparmor

Activer le service puis redémarrer pour valider l'état réel:

systemctl enable apparmor.service
systemctl start apparmor.service
reboot

Vérification

aa-status
cat /proc/cmdline | rg 'apparmor|security=apparmor|lsm='
lsmod | rg apparmor
cat /sys/kernel/security/lsm

État valide sur Morpheus

175 profils chargés.
119 profils en enforce.
7 profils en complain.
0 AVC deny récent sur la fenêtre de validation.
Les changements de politique sont suivis par auditd.

ausearch -m AVC -ts recent

Modes de fonctionnement

Enforce: bloque les actions non autorisées et log les violations.
Complain: log les violations potentielles sans bloquer, utile pour apprendre et tester.

aa-enforce <PROFILE_PATH>
aa-complain <PROFILE_PATH>
aa-status | rg 'enforce|complain'

Stratégie de déploiement

Services système matures: enforce.
Applications desktop complexes: complain au départ.
Navigateurs: prudence, sandbox native et interactions GPU/Wayland à considérer.
Chaque exception doit être documentée.

Gestion des profils

ls <APPARMOR_PROFILE_DIR>
aa-status
apparmor_parser -r <PROFILE_PATH>
aa-enforce <PROFILE_PATH>
aa-complain <PROFILE_PATH>
aa-disable <PROFILE_PATH>
systemctl reload apparmor.service

Analyse des logs

journalctl -k | rg apparmor
journalctl -kf | rg apparmor
dmesg | rg apparmor
aa-logprof
aa-logprof -f <APPARMOR_LOG_FILE>

DENIED indique un blocage en enforce. ALLOWED en complain indique une action qui aurait pu être bloquée.

Créer un profil personnalisé

aa-genprof <APPLICATION_BINARY>
apparmor_parser -r <CUSTOM_PROFILE>
aa-enforce <CUSTOM_PROFILE>
aa-status | rg '<APPLICATION_NAME>'

La version publique ne publie pas de profil complet. Elle montre seulement la logique: exécutable, fichiers de configuration, cache dédié, logs et refus explicites.

Sécurité apportée

Limitation d'accès aux fichiers hors rôle.
Restriction de capacités dangereuses selon profil.
Confinement de services comme impression, DNS ou outils réseau.
Réduction de l'impact d'un processus compromis.

Dépannage

journalctl -k | rg 'apparmor.*DENIED'
aa-status | rg '<APPLICATION_NAME>'
aa-complain <PROFILE_PATH>
aa-logprof
apparmor_parser -r <PROFILE_PATH>
systemctl reload apparmor.service

Passer temporairement en complain permet de confirmer qu'un profil est responsable sans désactiver toute la couche AppArmor.

Limitations

Certains profils officiels sont pensés pour d'autres distributions et demandent adaptation sur Arch.
Les applications desktop modernes sont difficiles à confiner proprement.
Les profils doivent évoluer avec les mises à jour et les nouveaux chemins.

Intégration avec d'autres outils

Firejail peut compléter AppArmor sur certaines applications desktop.
systemd peut associer un service à un profil AppArmor.
Docker/Podman peuvent utiliser des profils AppArmor.
auditd suit les changements de politique et refus utiles.

Commandes de référence rapide

aa-status
aa-enforce <PROFILE_PATH>
aa-complain <PROFILE_PATH>
aa-disable <PROFILE_PATH>
apparmor_parser -r <PROFILE_PATH>
systemctl reload apparmor.service
journalctl -k | rg apparmor
aa-logprof

Bonnes pratiques

Déployer progressivement: activation, complain, enforce, monitoring.
Surveiller régulièrement les refus récents.
Commenter les modifications de profils.
Sauvegarder ou versionner les profils modifiés.