&kppp; et les problèmes de sécurité Cette section est principalement pour les superutilisateurs (root) qui ont des demandes en haute sécurité, ou simplement les gens techniquement intéressés. Ce n'est pas nécessaire de lire cela si vous utilisez seulement &Linux; à la maison pour vous, mais vous pouvez apprendre une chose ou deux dans tous les cas. Restreindre les accès à &kppp; Un administrateur système peut vouloir restreindre l'accès à ceux qui sont autorisés à utiliser &kppp;. Il y a deux manières principales de faire cela. Restreindre l'accès avec les permissions de groupe Créez un nouveau groupe (vous pouvez le nommer numérotation ou similaire), et mettez-y tous les utilisateurs qui sont autorisés à utiliser &kppp;. Alors saisissez dans le prompt : # chown /opt/kde/bin/kppp # chmod /opt/kde/bin/kppp Cela suppose que &kde; a été installé dans /opt/kde/ et que votre nouveau groupe est nommé dialout. Restreindre l'accès à la manière de &kppp; Avant de faire quoi que ce soit, &kppp; vérifie s'il y a un fichier nommé /etc/kppp.allow. Si un tel fichier existe, seuls les utilisateurs nommés dans ce fichier sont autorisés à numéroter. Ce fichier doit être lisible par tout le monde (mais bien sûr NON accessible en écriture). Seuls les noms de login sont reconnus, ainsi vous ne pouvez pas utiliser UID dans ce fichier. Voici un court exemple : # /etc/kppp.allow # les lignes commentées comme celle-ci sont ignorées # tout comme les lignes vides fred karl daisy Dans l'exemple ci-dessus, seuls les utilisateurs fred, karl et daisy sont autorisés à numéroter, tout comme chaque utilisateur avec un UID de 0 (ainsi vous n'avez pas à mettre explicitement root dans le fichier). &kppp; a le bit <acronym >SUID</acronym > ? Que se passe-t-il au niveau sécurité ? Il est virtuellement impossible d'écrire un numéroteur sans le bit SUID qui est à la fois sûr et facile à utiliser pour les utilisateurs non expérimentés. &kppp; répond aux problèmes de sécurité avec la stratégie suivante. Immédiatement après que le programme débute, &kppp; fourche. Le processus maître, qui gère toutes les opérations de l'interface graphique comme l'interaction utilisateur, abandonne le droit SUID après la division/séparation en plusieurs processus, et tourne/continue avec les privilèges normaux de l'utilisateur. Le processus esclave garde ses privilèges, et est responsable de toutes les actions qui ont besoin des privilèges root. Pour garder cette partie sûre, aucune bibliothèque &kde; ou &Qt; n'est appelée ici, il y a juste de simples appels de bibliothèques. Le code source pour ce processus est court (environ 500 lignes) et bien documenté, ainsi il est facile pour vous de vérifier s'il y a des trous de sécurité. Les processus maître et esclave communiquent avec le standard &UNIX; IPC. Remerciement spécial à Harri Porten pour avoir écrit cette excellente partie de code. Il semblait que cela était impossible, mais il l'a fait en une semaine.