Droits et utilisateurs · Glossaire Linux

Permissions sur les fichiers

Trois actions (lire, écrire, exécuter) × trois cibles (propriétaire, groupe, autres) = neuf bits codés en octal ou symbolique. Les capacités complètent ce modèle en accordant à un programme un privilège précis de root.

`chmod`

Modifier les permissions d'un fichier ou répertoire

Chaque chiffre de la notation octale représente une cible (utilisateur, groupe, autres) et est la somme de :

Notation octale

4	Lecture (`r`)
2	Écriture (`w`)
1	Exécution (`x`)

Exemples courants

755	`rwxr-xr-x` — fichier exécutable lisible par tous.
644	`rw-r--r--` — fichier ordinaire lisible par tous.
700	`rwx------` — répertoire privé ou exécutable réservé au propriétaire. Pour une clé privée SSH, utiliser 600 plutôt que lui ajouter l'exécution.
600	`rw-------` — fichier sensible privé.

Visualisation des 9 bits (mode 755). Chaque groupe — user, group, others — possède trois bits indépendants. Bit actif : couleur d'accent. Bit inactif : grisé avec un -. La somme des bits actifs donne le chiffre octal.

Notation symbolique. Format : [ugoa][+-=][rwx]

Notation symbolique

u / g / o / a	Cible : user, group, others, all.
+ / - / =	Ajouter / retirer / fixer.
r / w / x	Le droit lui-même.

$ chmod 755 script.sh

Rend le script exécutable par tout le monde.

$ chmod u+x deploy.sh

Ajoute uniquement le droit d'exécution pour le propriétaire.

$ chmod -R g+w partagé/

Récursivement, donne le droit d'écriture au groupe sur tout le contenu du dossier.

$ chmod 600 ~/.ssh/id_rsa

Retire les droits du groupe et des autres sur une clé privée. 600 est un choix courant ; 400 peut aussi convenir. SSH vérifie notamment qu'une clé privée n'est pas accessible à d'autres utilisateurs, pas qu'elle possède exactement le mode 600.

Bits spéciaux

4xxx (SUID)	Le binaire s'exécute avec les droits du propriétaire (ex. `/usr/bin/passwd`).
2xxx (SGID)	Le binaire s'exécute avec les droits du groupe. Sur un dossier : nouveaux fichiers héritent du groupe.
1xxx (sticky)	Sur un répertoire : la suppression ou le renommage est réservé au propriétaire du fichier, au propriétaire du répertoire ou à un processus disposant des privilèges nécessaires. Exemple : /tmp.

À éviter : chmod 777 donne tous les droits à tout le monde. Solution de facilité dangereuse, presque toujours inappropriée. Préférez identifier la bonne combinaison propriétaire + groupe.

Voir aussi : chown umask ls stat

`chown`

Changer le propriétaire et/ou le groupe d'un fichier

Format : chown utilisateur:groupe fichier. Les deux parties sont optionnelles.

# chown alice rapport.pdf

Donne le fichier à l'utilisateur alice.

# chown alice:devs projet/

Change propriétaire et groupe en une commande.

# chown -R www-data:www-data /var/www/site

Récursif : tout le site appartient à l'utilisateur du serveur web.

# chown :devs partagé.txt

Change uniquement le groupe (le : initial est requis).

Attention : chown -R avec un mauvais utilisateur peut bloquer un service entier. Vérifiez toujours l'utilisateur cible avant.

Voir aussi : chmod id groupadd

`umask`

Permissions par défaut des nouveaux fichiers

umask définit les bits qui seront retirés des permissions par défaut. Les valeurs de base sont 666 pour les fichiers et 777 pour les répertoires.

$ umask
touch test.txt
ls -l test.txt

-rw-r--r-- 1 dev dev 0 mai 12 14:30 test.txt

Avec umask 022 et sans ACL par défaut, un fichier demandé en 0666 reçoit 0644 et un répertoire demandé en 0777 reçoit 0755. Le calcul retire des bits (mode demandé & ~umask) : ce n'est pas une soustraction arithmétique générale.

$ umask 077

Configuration paranoïaque : tous les nouveaux fichiers sont privés (600), dossiers (700).

Voir aussi : chmod touch mkdir

`getfacl · setfacl`

Donner des droits à des utilisateurs ou groupes précis (ACL)

Les permissions classiques ne connaissent qu'un propriétaire et un groupe. Les listes de contrôle d'accès (ACL) ajoutent des droits pour d'autres utilisateurs ou groupes nommés. Un + à la fin des droits dans ls -l signale qu'un fichier porte une ACL.

Options principales

getfacl FICHIER	Affiche les droits classiques et les ACL.
setfacl -m u:NOM:rwx	Ajoute ou modifie les droits d'un utilisateur ; `g:NOM:rx` pour un groupe.
setfacl -d -m ...	Définit une ACL par défaut, héritée par les fichiers créés dans le répertoire.
setfacl -x u:NOM	Retire l'entrée d'un utilisateur.
setfacl -b	Supprime toutes les ACL.
-R	Applique récursivement.

# setfacl -R -m u:bob:rwX /srv/projet
setfacl -R -d -m u:bob:rwX /srv/projet

Donne à bob l'accès au projet sans changer son propriétaire ni son groupe. La seconde ligne fait hériter ce droit aux fichiers créés ensuite. X majuscule n'ajoute l'exécution qu'aux répertoires et aux fichiers déjà exécutables.

$ getfacl /srv/projet

# file: srv/projet
# owner: alice
# group: alice
user::rwx
user:bob:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:bob:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

Les lignes default: sont les ACL héritées. La ligne mask plafonne les droits des entrées nommées et du groupe.

Le masque peut annuler une ACL : un chmod g-w sur un fichier avec ACL réduit aussi le masque, et donc les droits de tous les utilisateurs nommés. Vérifier avec getfacl après un chmod.

Voir aussi : chmod umask chattr

`chattr · lsattr`

Attributs étendus : fichier immuable ou en ajout seul

Les attributs étendus s'ajoutent aux permissions. Un fichier immuable (+i) ne peut être ni modifié, ni renommé, ni supprimé, même par root, tant que l'attribut n'est pas retiré. Pris en charge par ext4, XFS et Btrfs.

Attributs courants

+i / -i	Rend le fichier immuable, ou retire cette protection. Nécessite root.
+a / -a	Ajout seul : on peut écrire à la fin du fichier, jamais réécrire ni effacer. Utile pour un journal.
lsattr FICHIER	Affiche les attributs ; `-d` pour un répertoire lui-même.

# chattr +i /etc/resolv.conf
lsattr /etc/resolv.conf

----i----------------- /etc/resolv.conf

Empêche un outil de réécrire la configuration DNS. À utiliser avec parcimonie : une mise à jour qui doit modifier le fichier échouera.

$ lsattr -d /srv/archives

Avant de conclure à un problème de permissions quand root lui-même ne peut pas supprimer un fichier, vérifier ses attributs.

Voir aussi : chmod getfacl · setfacl stat

`getcap · setcap`

Donner à un programme un privilège précis sans le lancer en root

Le noyau découpe les pouvoirs de root en capacités distinctes : ouvrir un port inférieur à 1024 (CAP_NET_BIND_SERVICE), envoyer des paquets bruts (CAP_NET_RAW), etc. setcap attache une capacité à un exécutable, qui l'obtient au lancement sans être root ; getcap affiche celles qui sont attachées. Paquet libcap (Fedora) ou libcap2-bin (Debian, Ubuntu).

Commandes principales

getcap FICHIER	Affiche les capacités attachées à un exécutable.
getcap -r RÉPERTOIRE	Recherche récursivement les exécutables qui ont des capacités.
setcap CAP=+ep FICHIER	Attache une capacité, effective (`e`) et autorisée (`p`) au lancement.
setcap -r FICHIER	Retire toutes les capacités du fichier.

$ getcap -r /usr/bin /usr/sbin 2> /dev/null

Inventaire des exécutables qui disposent de privilèges particuliers : utile lors d'un audit de sécurité.

# setcap 'cap_net_bind_service=+ep' /usr/local/bin/mon-serveur
getcap /usr/local/bin/mon-serveur

/usr/local/bin/mon-serveur cap_net_bind_service=ep

Autorise ce programme à écouter sur le port 80 ou 443 tout en tournant sous un compte ordinaire.

Pour un service systemd : préférer AmbientCapabilities=CAP_NET_BIND_SERVICE dans l'unité. Une capacité posée avec setcap est perdue dès que le binaire est remplacé, par exemple lors d'une mise à jour.

Voir aussi : chmod sudo systemctl

Élévation des privilèges

Devenir root pour des opérations administratives, changer d'identité, et définir qui a le droit de le faire.

`sudo`

Exécuter une commande avec les droits d'un autre utilisateur (root par défaut)

sudo demande votre propre mot de passe (pas celui de root) et garde une session active de quelques minutes. Les droits sont définis dans /etc/sudoers, à éditer uniquement via visudo qui valide la syntaxe.

Options utiles

-u user	Exécute en tant qu'un autre utilisateur que root.
-i	Ouvre un shell de connexion comme root (équivalent `su -`).
-E	Demande la préservation de l'environnement, dans les limites autorisées par la politique sudo. Certaines variables restent filtrées et cette option peut être refusée.
-l	Liste les commandes que vous avez le droit d'exécuter.

$ sudo apt update

$ sudo -u postgres psql

Lance psql en tant qu'utilisateur postgres — pratique pour administrer la base.

$ sudo !!

Re-lance la commande précédente avec sudo (le grand classique quand on oublie).

Voir aussi : su usermod whoami

`su`

Changer d'utilisateur dans le shell courant

Demande le mot de passe de l'utilisateur cible (et non le vôtre). Sans argument, cible root.

$ su - alice

Ouvre un shell de connexion comme alice et se place dans son répertoire personnel. Bash lit ses fichiers de login (par exemple ~/.bash_profile ou ~/.profile) ; ~/.bashrc n'est chargé que si ces fichiers le demandent.

$ su -c "ls /root" root

Exécute une seule commande en tant que root puis revient.

Voir aussi : sudo whoami id

`visudo`

Modifier les règles sudo sans risquer de se bloquer

Les règles de sudo vivent dans /etc/sudoers et /etc/sudoers.d/. Une erreur de syntaxe dans ces fichiers peut bloquer toute élévation de privilèges. visudo ouvre le fichier dans l'éditeur, vérifie la syntaxe avant d'enregistrer et refuse une version invalide.

Options principales

visudo	Édite `/etc/sudoers` avec vérification.
-f FICHIER	Édite un autre fichier, typiquement dans `/etc/sudoers.d/`.
-c	Vérifie la syntaxe de tous les fichiers sans rien modifier.

# visudo -f /etc/sudoers.d/sauvegarde

Crée ou modifie une règle dans un fichier séparé, plus facile à suivre qu'une modification du fichier principal. Ce fichier doit appartenir à root avec le mode 0440, ce que visudo applique.

Syntaxe

# /etc/sudoers.d/sauvegarde — exemples de règles
%admins     ALL=(ALL)       ALL
sauvegarde  ALL=(root)      NOPASSWD: /usr/local/bin/sauvegarde.sh

# visudo -c

/etc/sudoers: parsed OK
/etc/sudoers.d/sauvegarde: parsed OK

À lancer après toute modification faite autrement qu'avec visudo.

Choisir l'éditeur : visudo respecte la variable EDITOR : sudo EDITOR=nano visudo pour éviter vi.

Voir aussi : sudo usermod nano

Gestion des comptes

Créer, modifier, et changer le mot de passe.

`useradd`

Créer un compte utilisateur

useradd crée un compte : entrée dans /etc/passwd et /etc/shadow, groupe, répertoire personnel si demandé. Ses valeurs par défaut viennent de /etc/login.defs et /etc/default/useradd.

Options principales

-m	Crée le répertoire personnel `/home/<nom>`.
-M / --no-create-home	Ne crée pas de répertoire personnel (utile pour un compte de service).
-r / --system	Compte système : UID choisi dans SYS_UID_MIN–SYS_UID_MAX de /etc/login.defs. Pas de home créé par défaut ; l'expiration du mot de passe n'est pas initialisée comme pour un compte ordinaire.
-s SHELL	Shell de connexion. `/bin/bash` pour un humain, `/usr/sbin/nologin` ou `/bin/false` pour un compte non interactif.
-G grp1,grp2	Ajoute aux groupes secondaires.
-c "Nom"	Champ commentaire (visible dans `/etc/passwd`).
-d /chemin	Chemin du home s'il diffère de `/home/<nom>`.

# useradd -m -s /bin/bash -G sudo,devs alice

Exemple Debian/Ubuntu : les groupes sudo et devs doivent exister. Sur Fedora/RHEL, le groupe d'administration est généralement wheel ; adapter -G et vérifier les groupes avec getent avant de créer le compte.

# passwd alice

Définit un mot de passe pour une connexion par mot de passe. Un compte peut utiliser d'autres méthodes d'authentification, par exemple une clé SSH, selon la configuration ; un mot de passe n'est donc pas toujours nécessaire.

Un compte de service dédié limite les droits Unix du programme. Un shell nologin et un mot de passe verrouillé empêchent les connexions ordinaires, mais n'obligent pas à passer par systemd : root peut aussi lancer directement une commande sous cette identité.

# useradd -r -U -s /usr/sbin/nologin -d /var/lib/myapp -M -c "MyApp service" myapp

Crée un compte système avec son groupe privé (-U), pour correspondre à User=myapp et Group=myapp dans l'unité. -r utilise la plage système configurée, -s choisit nologin et -M ne crée pas le home. Le compte est initialement verrouillé pour l'authentification par mot de passe ; le répertoire de données est créé ici par StateDirectory=myapp dans systemd.

Syntaxe

# /etc/systemd/system/myapp.service
[Unit]
Description=MyApp daemon
After=network.target

[Service]
Type=simple
User=myapp
Group=myapp
ExecStart=/usr/local/bin/myapp
Restart=on-failure
StateDirectory=myapp
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes

[Install]
WantedBy=multi-user.target

Ce que fait l'unité : l'unité systemd qui consomme le compte. Les directives User= / Group= font tourner le binaire sous l'identité du compte de service. Les options de durcissement (NoNewPrivileges, ProtectSystem=strict, ProtectHome=yes) ajoutent une couche de sandboxing au niveau du noyau, indépendante des permissions Unix.

nologin vs false : /usr/sbin/nologin refuse la connexion avec un message lisible (« This account is currently not available. »), /bin/false sort en silence avec un code 1. Les deux rendent toute connexion interactive impossible ; nologin est plus utile si quelqu'un tente un su - myapp par erreur.

Astuce : sur Debian/Ubuntu, la commande adduser (en français) est plus haut niveau et pose les questions interactivement. Elle reste cependant moins ciblée que useradd -r pour un compte de service — pour les démons, on garde useradd.

Voir aussi : usermod passwd systemctl

`usermod`

Modifier un compte existant

usermod modifie un compte existant : groupes, shell, répertoire personnel, verrouillage. La plupart des changements prennent effet à la prochaine connexion de l'utilisateur.

# usermod -aG docker alice

Ajoute alice au groupe docker sans retirer les autres groupes grâce à -aG. Pour un Docker avec démon rootful, l'accès à son socket donne généralement des capacités équivalentes à root : réserver ce groupe aux comptes administrateurs de confiance. Une nouvelle session est normalement nécessaire pour obtenir le groupe.

# usermod -L alice

Verrouille le mot de passe. Une connexion par clé SSH peut rester possible selon la configuration. -U déverrouille le mot de passe. Pour expirer le compte, utiliser séparément usermod --expiredate 1 alice ; cela ne termine pas les sessions ni les processus déjà ouverts.

# usermod -s /bin/zsh alice

Change le shell par défaut.

Piège classique : usermod -G groupe utilisateur sans le -a retire l'utilisateur de tous ses autres groupes. Toujours combiner -aG.

Voir aussi : useradd passwd id chage

`passwd`

Changer un mot de passe

passwd change le mot de passe de l'utilisateur courant. Lancé par root, il agit sur n'importe quel compte et permet aussi de le verrouiller ou d'en consulter l'état.

$ passwd

Change votre propre mot de passe (demande l'ancien).

# passwd alice

En tant que root, change celui d'alice sans connaître l'ancien.

# passwd -l alice

Verrouille le mot de passe. -u pour déverrouiller.

Voir aussi : chage usermod useradd

`chage`

Expiration et durée de vie des mots de passe

chage (change age) lit et modifie les champs de durée de vie d'un compte dans /etc/shadow : dernier changement, durée minimale entre deux changements, durée maximale avant obligation de changer, période d'avertissement, période d'inactivité avant verrouillage, date d'expiration. Outil clé pour appliquer une politique de mots de passe en entreprise.

Options principales

-l USER	List : affiche l'état actuel du compte (le seul flag utilisable sans root sur son propre compte).
-M JOURS	Durée maximale d'un mot de passe avant obligation de changement.
-m JOURS	Durée minimale entre deux changements (évite qu'un user contourne l'historique en changeant 5 fois d'affilée).
-W JOURS	Nombre de jours d'avertissement avant l'expiration.
-I JOURS	Inactivité après expiration avant verrouillage du compte.
-E AAAA-MM-JJ	Date d'expiration absolue du compte (différent du mot de passe : verrouille le compte entier).
-d 0	Force le changement de mot de passe à la prochaine connexion.

$ chage -l alice

Last password change                                    : May 14, 2026
Password expires                                        : Aug 12, 2026
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 90
Number of days of warning before password expires       : 7

Vue d'audit. Ici le compte exige un changement tous les 90 jours, avec 7 jours d'avertissement. chage -l est utilisable par l'utilisateur lui-même sur son propre compte — pratique pour vérifier quand on va se faire embêter.

# chage -M 90 -W 7 -I 30 alice

Politique typique : mot de passe valable 90 jours, alerte 7 jours avant, compte désactivé 30 jours après expiration si pas de changement. Combiné avec passwd -e pour forcer un premier changement à la prochaine connexion.

# chage -d 0 alice

Marque le mot de passe comme « jamais changé » → forcera alice à le redéfinir à sa prochaine connexion. Idiome après un reset administratif (création de compte avec mot de passe initial communiqué).

# chage -E 2026-12-31 stage-ete

Compte temporaire qui sera verrouillé au 31 décembre 2026 sans intervention. Combine bien avec useradd -e au moment de la création.

Politique globale : les défauts pour les futurs comptes sont dans /etc/login.defs (PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE). chage ne modifie que les comptes existants. Pour propager une politique en masse, un script qui boucle sur getent passwd et lance chage est la pratique courante.

Voir aussi : passwd useradd usermod

Groupes et identité

Gestion des groupes et inspection de l'identité courante.

`groupadd`

Créer un groupe

groupadd crée un groupe, qui permet de partager des droits entre plusieurs comptes : un répertoire de projet, l'accès à un périphérique ou à un service.

# groupadd developpeurs

# groupdel developpeurs

Suppression d'un groupe.

Pattern : répertoire partagé entre plusieurs utilisateurs. Quand plusieurs utilisateurs doivent collaborer sur les mêmes fichiers (équipe dev sur un répertoire commun, par exemple), trois ingrédients : un groupe dédié, le bit setgid sur le dossier (les nouveaux fichiers héritent automatiquement du groupe), et une umask qui rend les fichiers éditables par les membres du groupe.

# groupadd projet
usermod -aG projet alice
usermod -aG projet bob
mkdir -p /srv/projet
chgrp projet /srv/projet
chmod 2775 /srv/projet

Crée le groupe et le répertoire partagé avec setgid : les nouveaux fichiers héritent du groupe projet. Les membres ajoutés doivent ouvrir une nouvelle session (ou utiliser newgrp projet) pour que leurs processus obtiennent ce groupe. Le mode 2775 laisse aussi lecture et traversée aux autres ; choisir 2770 pour un répertoire réservé aux membres.

$ # Dans le ~/.bashrc des membres du groupe :
umask 0007

Avec umask 0007, un fichier créé avec le mode de base 0666 reçoit généralement 0660 (rw-rw----) et un répertoire créé avec 0777 reçoit 0770 (rwxrwx---). La umask n'ajoute pas de droit d'exécution ; une application peut demander des droits plus restrictifs et une ACL par défaut peut modifier le calcul.

Voir aussi : usermod chmod umask

`whoami`

Afficher le nom de l'utilisateur courant

whoami affiche le nom de l'utilisateur effectif. Utile après un sudo ou un su, ou dans un script qui doit vérifier sous quel compte il tourne.

$ whoami

dev

Particulièrement utile dans les scripts pour vérifier qu'on tourne bien sous root : [ "$(whoami)" = "root" ] || exit 1.

Voir aussi : id sudo who

`id`

Identifiants et groupes de l'utilisateur

id affiche l'UID, le GID et tous les groupes d'un utilisateur. C'est la vérification à faire quand un accès est refusé alors que le compte semble membre du bon groupe.

$ id

uid=1000(dev) gid=1000(dev) groupes=1000(dev),27(sudo),998(docker)

$ id -u    # UID seul
id -gn   # Nom du groupe primaire
id -nG   # Tous les groupes par leurs noms

Voir aussi : whoami getent groupadd

`getent`

Interroger les bases du système (passwd, group, hosts…)

getent requête les bases de données système via le sous-système NSS (Name Service Switch, configuré dans /etc/nsswitch.conf). Avantage sur un grep /etc/passwd : il voit aussi les comptes/groupes/hôtes provenant de LDAP, NIS, SSSD ou autres backends, pas seulement les fichiers locaux. À privilégier dans les scripts sur des environnements d'entreprise.

Bases interrogeables

passwd	Comptes utilisateurs (locaux + LDAP/SSSD).
group	Groupes et leurs membres.
hosts	Résolution de noms via NSS (combine `/etc/hosts` + DNS).
services	Mappage port ↔ nom (`/etc/services`).
shadow	Comptes avec hachages (root uniquement).
networks	Réseaux nommés.

$ getent passwd alice

alice:x:1001:1001:Alice:/home/alice:/bin/bash

Infos d'un compte au format /etc/passwd classique. Plus fiable que grep ^alice: /etc/passwd dès qu'il peut y avoir des comptes externalisés.

$ getent passwd 1001

Lookup par UID. Pratique quand un fichier appartient à un UID numérique inconnu : getent passwd $(stat -c %u fichier).

$ getent group docker

docker:x:998:alice,bob,charlie

Affiche l'entrée NSS du groupe et sa liste explicite de membres. Cette liste n'inclut pas forcément les utilisateurs dont c'est le groupe primaire ; utiliser id utilisateur pour vérifier l'ensemble des groupes d'un compte.

$ getent hosts api.exemple.fr

93.184.216.34   api.exemple.fr

Résolution DNS qui passe par /etc/hosts et le résolveur système — donc tient compte de l'ordre NSS, contrairement à dig qui parle directement à un serveur DNS. Bon test « est-ce que mon application verra le même résultat ? ».

$ getent services 443

https                 443/tcp

Quel service correspond au port 443 ? Inversement, getent services https donne le numéro.

Voir aussi : id whoami dig

Chiffrement et signatures

Chiffrer un fichier pour qu'il ne soit lisible que par son destinataire, signer pour qu'on puisse vérifier qu'il vient bien de soi. GPG (GNU Privacy Guard) est la boîte à outils historique sous Linux pour ces opérations — utilisée pour les mails (Thunderbird/Enigmail), la signature de paquets (Debian/Ubuntu/RPM), les commits Git signés, et les fichiers sensibles à transmettre.

`gpg`

Chiffrement asymétrique, signatures et gestion de keyring

gpg implémente OpenPGP : on génère une paire de clés (publique + privée), on partage la publique, et n'importe qui peut chiffrer un message à destination de notre clé privée — ou vérifier une signature qu'on a apposée. La clé privée est protégée par une passphrase. Le keyring local stocke les clés (les siennes et celles importées) dans ~/.gnupg/.

Gestion des clés

--gen-key / --full-generate-key	Génère une nouvelle paire de clés (interactif). `--full` pour choisir algo et durée.
--list-keys	Liste les clés publiques du keyring local.
--list-secret-keys	Liste les clés secrètes connues du trousseau, y compris des références à une carte ou à un agent ; cela ne prouve pas que leur passphrase est connue ni que la clé est disponible.
--export -a USER > pub.asc	Exporte sa clé publique en ASCII armored (à partager par mail/web).
--import FICHIER	Importe une clé reçue dans son keyring.
--delete-keys USER	Supprime une clé publique (utiliser `--delete-secret-keys` pour une privée).

Chiffrement et signature

-c FICHIER	Chiffrement symétrique (passphrase seule, pas de clé). Pratique pour soi-même.
-e -r DEST FICHIER	Encrypt à destination du contact `DEST` (cherché dans le keyring).
-d FICHIER.gpg	Decrypt : déchiffre vers stdout (ou `-o` pour un fichier).
--sign FICHIER	Signe (signature détachée binaire `.sig` avec `--detach-sign`).
--verify FICHIER.sig FICHIER	Vérifie la signature.
-a	ASCII armored : sortie en texte (extension `.asc`) au lieu de binaire.

$ gpg --full-generate-key

Première étape, une fois par identité. Choisir RSA and RSA, taille 4096, expiration 2 ans (renouvelable). La passphrase doit être solide et mémorisable — elle débloque la clé privée à chaque usage. Les clés résultantes sont stockées dans ~/.gnupg/.

$ gpg --list-keys
gpg --export -a alice@example.test > alice-pub.asc

Vérifier ses clés et exporter sa publique pour la partager (par mail, sur un keyserver, sur sa page web). Le fichier .asc contient un bloc texte lisible commençant par -----BEGIN PGP PUBLIC KEY BLOCK-----.

$ gpg -c secret.txt

Chiffrement symétrique rapide : passphrase tapée à l'invite, produit secret.txt.gpg. Idéal pour stocker un mot de passe ou un fichier sensible localement, sans avoir à gérer des clés. La passphrase est la seule chose qui permettra de déchiffrer.

$ gpg -e -r bob@example.test rapport.pdf

Chiffrement asymétrique : produit rapport.pdf.gpg que seul Bob (avec sa clé privée) pourra déchiffrer. Sa clé publique doit avoir été importée au préalable. Plusieurs -r permettent de chiffrer pour plusieurs destinataires d'un coup.

$ gpg --output rapport-dechiffre.pdf --decrypt rapport.pdf.gpg

Déchiffre vers un autre nom pour éviter de tronquer un fichier existant par une redirection shell avant de savoir si le déchiffrement réussit. GnuPG affiche une erreur si la clé nécessaire manque et peut demander une passphrase selon l'état de l'agent.

$ gpg --detach-sign -a release.tar.gz       # produit release.tar.gz.asc
gpg --verify release.tar.gz.asc release.tar.gz

Signature détachée : on ne modifie pas le fichier original, on crée juste un .asc à côté. Pattern classique pour distribuer un logiciel — l'utilisateur peut télécharger l'archive et la signature, vérifier que la signature correspond à la clé publique du mainteneur, et donc que le fichier n'a pas été altéré.

Trust on first use : Une signature correcte prouve la correspondance avec une clé, pas l'identité de son propriétaire. Comparer l'empreinte complète avec une source authentifiée. Dans le modèle Web of Trust, trust règle la confiance accordée au propriétaire pour certifier d'autres clés ; cela ne valide pas simplement sa propre identité. Après vérification, une certification locale gpg --lsign-key EMPREINTE est une opération distincte.

Sauvegarder ses clés : perdre la clé privée = perdre l'accès à tout ce qu'on a chiffré. Faire un export sécurisé hors-ligne : gpg --export-secret-keys -a alice@example.test > backup.asc puis stocker ce fichier sur un support hors-ligne (clé USB chiffrée, papier imprimé), pas dans le cloud. La passphrase reste indispensable pour utiliser la clé restaurée.

Voir aussi : ssh chmod tar

Contrôle d'accès (SELinux, AppArmor)

Au-dessus des permissions classiques (rwx, propriétaire/groupe), un contrôle d'accès obligatoire (MAC) contraint chaque programme par une politique, root compris. Deux systèmes coexistent selon la distribution : SELinux, actif par défaut sur Red Hat, Fedora, CentOS, Rocky et Alma, et AppArmor, sur Ubuntu, Debian et openSUSE. Quand « ça marche en le désactivant », c'est presque toujours un contexte, un booléen ou une règle de profil à corriger — pas une raison de le couper.

`getenforce · setenforce · semanage · restorecon`

Inspecter et corriger les contextes SELinux

Chaque fichier et chaque processus porte un contexte (user:role:type:level) ; la politique autorise ou refuse selon ces types. La grande majorité des soucis se résument à deux causes : un contexte de fichier incorrect (fichier déplacé avec mv qui conserve son ancien contexte) ou un booléen à activer. Les outils ci-dessous diagnostiquent et corrigent.

Modes et état

getenforce	Mode courant : `Enforcing` (applique), `Permissive` (journalise sans bloquer), `Disabled`.
sestatus	État détaillé (mode courant, mode au boot, politique chargée).
setenforce 0 / 1	Bascule Permissive / Enforcing temporairement (perdu au reboot). Permanent : `/etc/selinux/config`.
ls -Z / ps -Z	Affiche le contexte SELinux des fichiers / processus.

# getenforce
ls -Z /var/www/html/index.html

Enforcing
unconfined_u:object_r:httpd_sys_content_t:s0 index.html

Le type httpd_sys_content_t est ce qui autorise Apache à lire le fichier. Si une page renvoie un 403 alors que les permissions rwx sont correctes, c'est typiquement ce contexte qui cloche.

# restorecon -Rv /var/www/html
semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
restorecon -Rv /srv/web

restorecon réapplique le contexte par défaut attendu pour le chemin — la correction la plus fréquente, après un mv. Pour un chemin non standard (servir le web depuis /srv), on enregistre d'abord la règle avec semanage fcontext puis on l'applique. chcon ferait un changement ponctuel, mais non persistant à un restorecon ultérieur.

# getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

Les booléens activent des comportements sans toucher aux contextes — ici, autoriser Apache à ouvrir des connexions sortantes (proxy, base distante). -P rend le réglage permanent.

Diagnostiquer un refus : les blocages SELinux sont journalisés dans /var/log/audit/audit.log. ausearch -m avc -ts recent liste les refus récents, et audit2why les explique en clair (souvent avec la commande exacte pour corriger). Passer brièvement en Permissive confirme que SELinux est bien la cause avant de chercher la règle.

Voir aussi : chmod chown journalctl AppArmor

`aa-status · aa-enforce · aa-complain`

Inspecter et ajuster les profils AppArmor

AppArmor est le contrôle d'accès obligatoire d'Ubuntu, de Debian et d'openSUSE. Au lieu d'étiqueter chaque fichier comme SELinux, il associe un profil à un exécutable : la liste des fichiers et des capacités auxquels il a droit. Un profil est soit en mode enforce (il bloque), soit en mode complain (il journalise sans bloquer). aa-enforce et aa-complain viennent du paquet apparmor-utils.

Commandes principales

aa-status	Profils chargés, leur mode et les processus confinés.
aa-enforce PROFIL	Passe un profil en mode enforce.
aa-complain PROFIL	Passe un profil en mode complain, pour diagnostiquer.
aa-disable PROFIL	Désactive un profil.
apparmor_parser -r FICHIER	Recharge un profil après modification.

# aa-status

apparmor module is loaded.
42 profiles are loaded.
38 profiles are in enforce mode.
4 profiles are in complain mode.

Les lignes suivantes détaillent chaque profil et les processus qu'il confine.

# journalctl -k | grep 'apparmor="DENIED"'

Les refus apparaissent dans les messages du noyau, avec le profil, l'opération et le fichier en cause.

# aa-complain /etc/apparmor.d/usr.sbin.nginx
aa-enforce /etc/apparmor.d/usr.sbin.nginx

Passer en complain le temps de reproduire le problème, ajuster le profil, puis revenir en enforce.

Ajuster un profil : après avoir reproduit le problème en mode complain, aa-logprof lit les journaux et propose les règles à ajouter au profil.

Voir aussi : SELinux journalctl