Temps prévu : 2h
2.5 Ouverture de session & profil¶
☕ À la machine à café de CorpTech
2 collègues à la machine à café :
- « Au fait, le compte
invite2existe toujours ? » - « Je ne crois pas. J’ai cru comprendre qu’on devait maintenant utiliser nos comptes individuels… et il y a aussi une histoire de groupes. Je n’ai pas tout compris ; en tout cas, pour moi, ça ne marche plus… »
- « Ah… du coup, avant ça marchait, mais on ne savait pas pourquoi. Et maintenant, ça ne marche plus… mais au moins, on sait pourquoi… » 😤
Cette situation met en évidence un point essentiel :
Tant que les accès étaient contournés, le système avait l'air de “fonctionner” mais sans être compris. Désormais, il est nécessaire de comprendre ce qui se passe réellement lorsqu’un utilisateur se connecte.
Sur un système Unix/Linux, il est essentiel de distinguer l’authentification de l’ouverture de session, même si ces deux étapes sont souvent assurées par le même programme (login en local, sshd à distance).
L’authentification répond à la question « Qui es tu ? ».
Elle consiste uniquement à vérifier une identité à l’aide d’un mot de passe ou d’une clé SSH. Conceptuellement, cette étape s’appuie sur /etc/shadow, qui contient les informations nécessaires à la validation de l’identité. Tant que l’authentification n’a pas abouti, aucun contexte utilisateur n’est créé : aucun UID n’est appliqué et aucun programme utilisateur n’est lancé.
Une fois l’identité validée, vient l’ouverture de session. Cette étape définit le contexte d’exécution sur le système. Elle s’appuie sur /etc/passwd et /etc/group, qui fournissent l’UID, les groupes, le répertoire personnel et le programme associé au compte. C’est à ce moment-là que la session utilisateur est réellement créée.
Le programme associé au compte est alors lancé dans cette session. Il s’agit le plus souvent d’un shell interactif, mais ce choix dépend de l’usage prévu pour le compte.
En résumé :
/etc/shadow sert à authentifier,
/etc/passwd et /etc/group servent à ouvrir une session,
et le programme associé au compte est exécuté dans cette session.
Le shell n’est pas obligatoire
Tous les comptes Unix/Linux n’ont pas vocation à disposer d’un shell interactif. Certains sont destinés uniquement à l’exécution de services ou de commandes automatiques ; leur associer un programme non interactif permet de restreindre l’accès au système. Le shell est donc un outil réservé aux sessions interactives, pas une obligation générale.
Travaux dirigés : Connexion SSH vs connexion locale¶
Nous allons observer la différence entre une connexion distante (SSH) et une connexion locale (console / tty). Le but est de comprendre quel programme authentifie, quand une session est créée, et ce que devient le shell.
Pré-requis
Vous devez absolutment avoir aucun compte de connecté sur votre VM. Si vous avez fait des manipulations et qu'une session est ouverte en local ou à distance fermez absolument tout en tapant exit, autant de fois qu'il le faudra pour n'avoir plus que l'invite de loggin qui s'affiche.
Étape 1: Connexion SSH¶
Depuis une machine distante connectez-vous à l'aide de ssh:
ssh alice@IP_DE_LA_VM
puis
alpine:~$ ps | grep alice
Résultats attendu:
2514 root 0:00 sshd-session: alice [priv]
2516 alice 0:00 sshd-session: alice@pts/0
2517 alice 0:00 -sh
2666 alice 0:00 ps
2667 alice 0:00 grep alice
alpine:~$
puis fermez la session ssh avec la commande exit.
Explications
La sortie de ps montre que la connexion SSH est d’abord prise en charge par un processus exécuté avec l’identité root, visible sous la forme sshd-session: alice [priv]. Ce processus assure l’authentification et prépare l’ouverture de la session. Une fois l’identité validée, la session utilisateur est ouverte et apparaît sous la forme sshd-session: alice@pts/0, cette fois exécutée avec l’identité de alice. Le shell (-sh) est ensuite lancé dans cette session et permet l’exécution des commandes.
Étape 2: Connexion local¶
Depuis la console VirtualBox (tty) connectez vous avec le même compte alice, puis, dans cette session locale :
ps | grep alice
Résultats attendu:
alpine:~$ ps | grep alice
2712 root 0:00 /bin/login -- alice
2713 alice 0:00 -sh
2716 alice 0:00 ps
2717 alice 0:00 grep alice
alpine:~$
Explications
La sortie de ps montre que la connexion locale est prise en charge par le programme login, exécuté avec l’identité root, visible sous la forme /bin/login -- alice. Ce processus assure l’authentification de l’utilisateur et déclenche l’ouverture de la session. Une fois l’identité validée, la session utilisateur est ouverte avec l’identité de alice, puis le programme associé au compte est lancé, ici un shell (-sh) afin de pourvoir intéragir avec le système.
On a constaté que, selon le mode d’accès, des programmes différents assurent l’authentification, tandis que le déroulement de l'ouverture de session reste identique. Dans le cas d’une connexion distante, l’authentification est prise en charge par sshd ; dans le cas d’une connexion locale, elle est assurée par login.
Une fois l’identité validée, le système procède à l’ouverture d’une session utilisateur. Cette session est associée à l’identité de l’utilisateur (UID, groupes, environnement) et constitue le contexte d’exécution sur le système. Le programme associé au compte est alors lancé dans cette session, le plus souvent un shell interactif ce qui permet l’exécution des commandes.
Il faut retenir que ce n’est pas le shell qui est responsable de l’authentification ni de la création de la session : il s’agit simplement d’un programme exécuté dans une session déjà ouverte.
2.4.2 L’environnement de session et les profils¶
Lors de l’ouverture d’une session sur un système POSIX, le shell exécute /etc/profile, puis ~/.profile s’il existe.
Ces fichiers définissent l’environnement de la session.
Le fichier /etc/profile définit l’environnement commun à tous les utilisateurs du système.
Le fichier ~/.profile permet à un utilisateur particulier de compléter ou de modifier cet environnement pour sa propre session.
~ et $HOME
~ et $HOME désignent le répertoire personnel de l’utilisateur. Par exemple, pour l’utilisateur alice, ~ correspond à /home/alice.
Parmi les paramètres définis lors de l’ouverture d’une session, certains influencent directement les droits appliqués aux fichiers et répertoires créés par l’utilisateur.
L’un de ces paramètres est umask.
2.4.3 Le paramètre umask¶
Lorsqu’un utilisateur crée un fichier ou un répertoire, le système ne choisit pas les permissions au hasard.
Il applique des permissions par défaut, puis retire automatiquement certains droits à l’aide d’un paramètre appelé umask.
Le umask est un masque de permissions associé à un processus.
Il est appliqué uniquement au moment de la création d’un fichier ou d’un répertoire.
Il n’a aucun effet rétroactif sur des objets déjà existants.
Le rôle du umask est de retirer des permissions, jamais d’en ajouter.
Permissions par défaut¶
Par convention POSIX, les permissions de départ sont : - 777 pour un répertoire ; - 666 pour un fichier.
Le umask est alors soustrait à ces valeurs pour produire les permissions finales.
Avec un umask de 022 : - un répertoire est créé avec les droits 755 ; - un fichier est créé avec les droits 644.
Observation du umask¶
Affichez la valeur actuelle du umask :
umask
Créez ensuite un fichier et observez ses permissions :
touch test1
ls -l test1
Les droits observés correspondent aux permissions par défaut moins le umask.
Modification du umask¶
Changez le umask pour la session en cours :
umask 077
Créez un nouveau fichier :
touch test2
ls -l test2
Le second fichier est créé avec des permissions plus restrictives.
Le premier fichier n’est pas modifié.
Cela montre que le umask agit uniquement lors de la création.
Portée et limites du umask¶
Le umask est un paramètre de processus, hérité par les processus fils.
Il s’applique à tous les fichiers et répertoires créés depuis la session.
Le umask n’est pas un mécanisme de sécurité fort.
Il ne corrige pas des permissions incorrectes sur un répertoire existant.
Il ne protège pas contre une modification volontaire des droits après création.
Son rôle est de définir une politique de droits par défaut cohérente.
Mise en place d’une politique globale¶
Pour appliquer un umask identique à toutes les sessions utilisateur, il doit être défini dans le profil système.
Éditez le fichier /etc/profile en tant que root :
nano /etc/profile
Ajoutez en fin de fichier :
umask 027
Ce réglage s’appliquera à toute nouvelle session ouverte sur le système.
Questions
Quels seront les droits par défaut : - d’un fichier créé par un utilisateur ? - d’un répertoire créé par un utilisateur ?
Bonus .profile¶
Pour vous facilitez l'administration, on peut utiliser le .profile de root pour afficher un bandeau d'information .
1) Connectez-vous à root 2) Créez le fichier .profile à la $HOME de root (c-à-d /root) 3) Collez ceci:
clear
# Affichage uniquement pour un shell interactif sur un terminal
case "$-" in *i*) ;; *) return ;; esac
[ -t 1 ] || return
_user="${USER:-root}"
_host="$(hostname 2>/dev/null)"
_date="$(date 2>/dev/null)"
_connexion="locale"
# Vérifie si la variable SSH_CONNECTION est définie pour déterminer le type d'accès
[ -n "$SSH_CONNECTION" ] && _connexion="SSH"
# Récupération de l'uptime et nettoyage de la chaîne pour l'affichage
_uptime="$(uptime 2>/dev/null | sed 's/.*up \([^,]*\),.*/\1/' | sed 's/^ *//')"
[ -n "$_uptime" ] || _uptime="(inconnu)"
_disk="$(df -h / 2>/dev/null | awk 'NR==2{print $4 " libres / " $2 " (" $5 " utilisé)"}')"
[ -n "$_disk" ] || _disk="(inconnu)"
_sessions="$(who 2>/dev/null | wc -l | tr -d ' ')"
[ -n "$_sessions" ] || _sessions="?"
# Interfaces réseau IPv4 (alignées)
# Utilisation de ip -4 addr pour ne récupérer que les IP v4
_net_lines="$(ip -4 addr show scope global 2>/dev/null | awk '
/^[0-9]+:/ {iface=$2; sub(":", "", iface)}
/inet / {printf "%-10s : %s\n", iface, $2}
')"
[ -n "$_net_lines" ] || _net_lines="(aucune)"
# Route par défaut (simplifiée)
_route="$(ip route show default 2>/dev/null | head -n1 | awk '{print "via " $3 " dev " $5}')"
[ -n "$_route" ] || _route="(aucune)"
print_line() {
# Tronque à 48 caractères max pour éviter tout débordement
printf "│ %-48.48s │\n" "$1"
}
print_sep() {
printf "├──────────────────────────────────────────────────┤\n"
}
print_top() {
printf "┌──────────────────────────────────────────────────┐\n"
}
print_bottom() {
printf "└──────────────────────────────────────────────────┘\n"
}
print_top
print_line "SESSION ADMINISTRATEUR"
print_sep
print_line "Utilisateur : ${_user}@${_host}"
print_line "Connexion : ${_connexion}"
print_sep
printf "%s\n" "$_net_lines" | while IFS= read -r l; do
print_line "$l"
done
print_line "Route def. : ${_route}"
print_sep
print_line "Date : ${_date}"
print_line "Uptime : ${_uptime}"
print_line "Disque / : ${_disk}"
print_line "Sessions : ${_sessions}"
print_bottom
Conclusion
Au cours de ce TP, vous avez identifié les différentes étapes qui mènent à l’accès au système : l’authentification, l’ouverture de session et la mise en place de l’environnement utilisateur. Vous avez observé le rôle réel des programmes impliqués (login, sshd, le shell), ainsi que l’influence des profils et du umask sur le contexte de travail. À partir de ces mécanismes fondamentaux, à vous d’imaginer ce qu’il est possible de mettre en place pour contrôler, restreindre ou adapter l’accès au système selon les usages et les besoins