\documentclass[french,a4paper]{article} \usepackage[latin1]{inputenc} \usepackage[T1]{fontenc} \usepackage{babel} \usepackage{graphicx} \usepackage{url} \usepackage{alltt} \usepackage{varioref} \usepackage{hyperref} \title{Kollectiv' admin} \author{intrigeri [intrigeri@squat.net]} \begin{document} \maketitle \begin {abstract} Ce document vise à proposer un schéma d'administration \emph{collective} et \emph{formalisée} d'un parc d'ordinateurs, dans un contexte nécessitant de prêter une attention particulière aux questions de sécurité informatique. \end{abstract} \newpage \tableofcontents \newpage \subsection{Changelog} \label{sec:changelog} \begin{itemize} \item 2003 02 17: version initiale \item 2003 04 04: \begin{itemize} \item quelques clarifications langagières \item précision plus grande au niveau des relations entre \textit{blocs} d'admin \end{itemize} \item 2003 04 05: annexes \item 2003 04 14: début de conversion en \TeX \item 2003 04 19: fin de la conversion \item 2003 04 20: écriture du Makefile \item 2003 05 10: plein de clarifications/ajouts \item 2003 05 29: réorganisation complète de ce document, recentrage sur les objectifs initiaux, peaufinages divers \item 2003 06 07: version RFC \end{itemize} \subsection{TODO} \begin{itemize} \item préciser que les rôles des adminEs peuvent évoluer dans le temps \item comment gérer les dépendances entre blocs d'admin ? \item scripts permettant la gestion des admins ? \item paquet Debian \og ala AlternC\fg{} ? \end{itemize} \newpage \section{Analyse du problème} \subsection{Politique} Le fait d'administrer des ordinateurs collectifs ou un serveur n'est pas anodin ; cela implique : \begin{itemize} \item un \og contrat de confiance\fg{} avec les utilisateurices ; \item une grande disponibilité pour être réactif/ve en cas de problème; \item du temps et de la régularité pour la maintenance; \end{itemize} De plus, il est souhaitable, dans le cadre de l'administration collective d'un parc informatique, de mettre en place des solutions respectant les contraintes suivantes : \begin{itemize} \item non-concentration du pouvoir ; \item répartition du travail sur quelques cerveaux coopérants; \item gestion et suivi aisés de la partie commune de l'administration; \item simplicité de la transmission de tâches/responsabilités. \end{itemize} Quelques précisions avant de mettre les mains dans le cambouis... \begin{itemize} \item la confrontation de ce modèle théorique avec l'expérience vécue ne manquera pas, soyons-en sûrEs, de remettre en cause certains des choix de ce document... et tant mieux ! \item l'auteur principal étant quelque peu novice en la matière, il est fort probable que des absurdités se soient glissées dans ce document... merci de les lui signaler. \end{itemize} \subsection{Technique} \subsubsection{Permissions des adminEs} Le choix qui a été fait est de ne pas divulguer les mots de passe root des machines, mais plutôt de donner aux adminEs les permissions nécessaires par l'intermédiaire de sudo. D'autre part, on ne peut évidemment pas administrer un serveur indépendamment des machines clientes (exemple: cas d'un serveur d'authentification) ; il est donc logique de confier aux adminEs d'un service la gestion des logiciels correspondants sur les machines clientes. Afin de simplifier notre modélisation, on supposera que, pour administrer un service donné, unE adminE a besoin des mêmes permissions sur le serveur que sur les machines clientes. Une solution satisfaisant à ces contraintes est proposée dans l'annexe \ref{sec:dist-sudo}. \subsubsection{Outils de partage d'information} Les réplications d'informations nécessaires entre les machines sont notamment sources : \begin{itemize} \item de complexification, \item de vulnérabilités, \item d'incohérences des données entre les machines. \end{itemize} Pour ces raisons, on veillera à éviter ces duplications au maximum, en choisissant autant que possible des solutions capables d'utiliser les informations centralisées sur un serveur; cette direction donnée à notre réflexion vaut en particulier pour : \begin{itemize} \item la gestion et l'authentification des comptes utilisateurices; \item le suivi des modifications de la configuration des machines; \item le suivi des problèmes. \end{itemize} Pour une réflexion sur les outils qui seront utilisés pour partager ces informations, on se référera aux annexes \ref{sec:changelogs} et \ref{sec:bug-tracking}. \newpage \section{Et concrètement... comment procéder ?} Dans cette partie, nous décrirons un mode opératoire permettant de modéliser et de mettre en place le système d'administration collective proposé dans ce document. \subsection{Audit des besoins et moyens} \label{sec:besoins-et-moyens} La validité de la modélisation dépend, en bonne partie, de la rigueur avec laquelle on effectuera les audits suivants : \begin{itemize} \item lister les services à mettre en place sur la machine ; \item établir les relations de dépendance entre ces services; \item en déduire l'étendue de la partie commune à touTEs les admin-e-s; \item lister les moyens humains disponibles : affinités, disponibilités coïncidentes, temps disponible, compétences, etc. \end{itemize} \subsection{Répartition des tâches} \label{sec:repartition-des-taches} À partir des données rassemblées à l'étape \ref{sec:besoins-et-moyens} : \begin{itemize} \item définir des sous-ensembles de tâches à effectuer, qu'on nommera dorénavant des \textit{blocs} d'admin, qui ne se recoupent pas entre eux ; pour les matheuxEs, il s'agit de réaliser une \textit{partition} de l'ensemble des tâches à effectuer ; \item définir des sous-ensembles de personnes, qu'on nommera dorénavant des \textit{équipes} d'admin ; le nombre de ces équipes doit évidemment être au maximum égal au nombre de blocs... ; \item assigner une équipe à chaque bloc; \item déduire de l'étape \ref{sec:besoins-et-moyens} les relations de dépendance entre les blocs d'admin, selon la règle suivante :\\ \\ \begin{math} \textrm{le bloc } A \textrm{ dépend du bloc } B\\ \leftrightarrow\\ %\equiv \exists (\textrm{un élément } a \in A \textrm{ et un élément } b \in B) \textrm{ tels que } a \textrm{ dépend de } b \end{math} \end{itemize} \subsection{Conception de la communisation des informations} \label{sec:conception-communisation} \begin{itemize} \item choix des différents groupes/users/privilèges sudo, en fonction de la répartition des tâches effectuée à l'étape \ref{sec:repartition-des-taches}. \item en fonction de l'échelle du parc informatique (quantité de machines et de services à administrer) choix des procédures et outils de partage des informations; cf. annexes \ref{sec:changelogs} et \ref{sec:bug-tracking}. \end{itemize} \subsection{Implémentation du modèle} Il s'agit de : \begin{itemize} \item installation et paramétrage du système d'exploitation et de la partie commune \item installation, par les adminEs concernéEs, des services nécessaires pour la suite \item mise en place des outils de partage d'information prévus à l'étape \ref{sec:conception-communisation} \end{itemize} \newpage \appendix{} \section{Distribution des droits des adminEs} \label{sec:dist-sudo} On l'a vu, les adminEs doivent avoir accès aux machines clientes, avec les mêmes permissions que sur le serveur, pour pouvoir les administrer. Comme toutE autre utilisateurice, unE adminE se connectant sur une machine cliente se verra authentifiéE sur le serveur. Puis vient le moment où ille utilise sudo; sudo, tout d'abord, authentifie l'adminE sur le serveur central, via l'utilisation de PAM (Pluggable Authentication Modules) sur la machine cliente. Mais la difficulté est ailleurs: sudo ne sait stocker \emph{que} dans le fichier \texttt{/etc/sudoers} les permissions détaillées attribuées aux adminEs ; afin de gérer tout ceci de façon centralisée, il nous faut utiliser un système sécurisé de partage ou réplication de fichiers pour \texttt{/etc/sudoers}. Le logiciel cfengine (http://www.cfengine.org/) semble remplir cette tâche à merveille. \section{Suivi et diffusion des changements} \label{sec:changelogs} Dans notre cadre de travail collaboratif, les membres d'une équipe d'adminEs doivent être informéEs des modifications de configuration effectuées par l'unE d'entre elleux. Il faut donc mettre en place un système permettant non seulement d'enregistrer ces modifications, mais aussi de les faire parvenir à qui de droit. \subsection{Suivi des changements} Pour enregistrer les modifications de configuration effectuées, différentes méthodes s'offrent à nous : \begin{itemize} \item fichiers Changelog édités à la main par les adminEs ; cette solution a l'indéniable avantage de la simplicité, mais elle part du principe que les adminEs seront rigoureuxes et renseigneront systématiquement et correctement le Changelog approprié... cette supposition est peut-être un tantinet optimiste ;) \item GNU RCS (Revision Control System) sauvegarde les modifications effectuées sur les fichiers qu'on lui confie ; c'est sur ce logiciel que se base CVS, qui lui est plutôt conçu pour gérer, à travers le réseau, des arborescences complètes, alors que RCS en reste à l'échelle du fichier et d'une machine. \end{itemize} \subsection{Diffusion des Changelogs} Afin de diffuser les modifications des Changelogs, une solution commode consiste en la création d'une liste de discussion par équipe d'admin, plus une ML commune à tou-te-s les adminEs; ainsi, il suffira de mettre en place un système qui envoie des mails aux listes concernées en cas de modification des Changelogs ; si RCS est choisi, rcs-report fait exactement ce travail ; sinon, diffmon est une solution à étudier. Pour éviter que ces emails ne passent en clair sur le réseau, plusieurs solutions existent, selon le cas on choisira la plus adaptée: \begin{itemize} \item inscrire aux ML l'utilisateurice de chaque adminE sur le serveur d'administration... c'est le plus simple, on n'a pas besoin de cryptage dans ce cas là car les mails ne sortent pas du serveur; \item utiliser une clé gpg par équipe d'admin et crypter les mails avant qu'ils ne soient envoyés sur la liste; \item utiliser la version patchée de Mailman: \newline cf. http://www.nah6.com/products/secure-list/. \end{itemize} \section{Suivi des problèmes} \label{sec:bug-tracking} Tout d'abord, pourquoi suivre les problèmes avec un logiciel spécialisé ? On pourrait en effet considérer cette méthode comme trop lourde, trop compliquée, cependant... un tel logiciel sert : \begin{itemize} \item pour ne pas oublier dans un coin certains problèmes, en se promettant d'y revenir plus tard; \item pour que toutE unE chacunE puisse signaler des problèmes. \end{itemize} Pour ce faire, d'excellents outils libres existent ; par exemple : \begin{itemize} \item RT (perl/mysql), utilisé sur stallman.indymedia.org ; il n'est hélas pas packagé en Debian, mais sait s'authentifier sur le serveur web :\newline http://www.bestpractical.com/rt/ \item Bugzilla (perl/mysql), très complet en version 2.14.2 sur Woody ; cette version n'est plus supportée par l'équipe de développement... et a des trous de sécurité ; la dernière version stable (2.16.3) est dans Sarge :\newline http://www.mozilla.org/projects/bugzilla/ \item Debian bug tracking software (perl/?) ; un peu roots :\newline http://www.chiark.greenend.org.uk/~ian/debbugs/ \item Mantis (php/mysql) :\newline http://mantisbt.sourceforge.net/ \item GNU GNATS (?/txt) :\newline http://www.gnu.org/software/gnats/ \end{itemize} Idéalement, le logiciel choisi doit être capable de s'authentifier sur l'annuaire centralisé d'utilisateurices qui aura été choisi. Seul RT remplit cette condition, car il sait s'authentifier sur Apache, donc, par transitivité, sur PAM et/ou LDAP. \end{document} \bye