Linux Attitude

Niveau :      
Résumé : openssl

Vérification

Maintenant que nous avons des certificats propres et bien signés il va falloir les vérifier. Mais il ne s'agit pas simplement de vérifier que le certificat est valide et signé par une autorité de confiance. Tout d'abord, il fautde vérifier toute sa chaine de confiance. Ensuite il faut vérifier ses extensions, par exemple s'il va être utilisé pour les usages auxquels on l'a prévu.

Openssl permet de faire la vérification de la chaine de certification ainsi que la vérification de l'usage. Pour cela il faut installer l'autorité de confiance :

# On trouve le hash du certificat de l'AC
$ hash=$(openssl x509 -hash -noout -in cacert.pem)
# On installe l'AC en utilisant ce hash (il faut être root ici)
$ cp cacert.pem /etc/ssl/certs/$hash.0

Du coup la vérification d'un certificat se fait simplement :

$ openssl verify -purpose sslclient certificat.crt

Pour la vérification des extensions, il faut voir au cas par cas.

Mais contrairement à ce qu'on pense souvent, ce n'est pas tout. Il faut aussi vérifier que le certificat n'est pas révoqué, c'est-à-dire invalidé avant la date limite.

Révocation

La révocation d'un certificat se fait dans plusieurs cas :

• perte de la clé
• départ du propriétaire de la clé
• renouvellement de la clé
• ...

En gros à chaque fois qu'on veut garantir que la clé ne sera plus utilisée.

Pour révoquer un certificat alors qu'on a installé une AC openssl comme dans l'article précédent :

# On en profite pour indiquer pourquoi on le révoque
# les raisons possibles sont : unspecified, keyCompromise, CACompromise,
#   affiliationChanged, superseded, cessationOfOperation, certificateHold or removeFromCRL
$ openssl ca -config openssl.cnf -revoke client.cert -crl_reason keyCompromise

Il existe 2 mécanismes pour faire savoir au monde qu'on a révoqué un certificat : les CRL et le protocole OCSP.

Niveau :      
Résumé :

Après avoir vu il y a longtemps comment créer le certificat d'une autorité de certification personnelle et comment l'installer là où c'est nécessaire, nous allons voir les méthodes pour gérer une autorité de certification.

Une fois l'autorité créée, l'activité principale d'une autorité est de signer des certificats. Et plutôt que de taper tous les paramètres à la main, il est plus simple de disposer d'une configuration, ce qu'openssl nous propose. De plus, openssl dispose d'une commande permettant une gestion simplifiée d'une autorité.

Passons en revue la configuration (reprise du fichier par défaut /etc/ssl/openssl.cnf). Parlons directement de la section gérant l'autorité elle-même :

# Section pour la commande ca
[ ca ]
# Autorité par défaut (pour en gérer plusieurs)
default_ca      = Peck_authority 

# Section spécifique à mon autorité
[ Peck_authority ]

# Tous les répertoires de base
dir             = /srv/Authority        # Where everything is kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
new_certs_dir   = $dir/newcerts         # default place for new certs.

certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number
crlnumber       = $dir/crlnumber        # the current crl number
                                        # must be commented out to leave a V1 CRL
private_key     = $dir/private/cakey.pem# The private key
RANDFILE        = $dir/private/.rand    # private random number file

Ensuite les options spécifiques :

# Mettre à no pour permettre à une entité de disposer de plusieurs certificats
#unique_subject = no

# Section contenant les extensions à utiliser
x509_extensions = usr_cert              # The extentions to add to the cert

# Format d'affichage des données en ligne de commande
name_opt        = ca_default            # Subject Name options
cert_opt        = ca_default            # Certificate field options

# Ne pas utiliser sauf à faire infiniment confiance aux demandeurs (ou tout vérifier à la main)
# copy_extensions = copy

# Durée de validité des certificats émis
default_days    = 365
# Fonction de hashage à utiliser (ne pas utiliser md5 :-)
default_md      = sha1
# Réécrire le DN passé par le demandeur
preserve        = no

# Politique à utiliser pour la vérification de la demande
policy          = policy_match

Et maintenant les sous-sections.

Niveau :      
Résumé : SSH et certificats x509

Vous avez une ferme de serveurs ? Vous avez une ferme d'utilisateurs ? Vous avez déjà une infrastructure de gestion de clés pour des certificats x509 (ssl) ?

Si vous répondez oui à deux de ces points alors cet article va vous intéresser.

Sachez qu'il est possible d'utiliser des certificats x509 avec ssh. Quel intérêt ? Tout simplement vous pouvez réutiliser votre PKI si vous en avez déjà une en x509. Ensuite les certificats fonctionnent par un système de signature hiérarchisée, donc il n'est plus nécessaire de mettre en place un système de distribution des clés des utilisateurs sur les machines. Et inversement, les utilisateurs n'auront plus à se reposer sur leur pifomètre pour accepter les clés des serveurs à leur première connexion.

Maintenant qu'on sait qu'on va pouvoir vendre de la sécurité à notre boss tout en évitant de se farcir des systèmes de synchronisation, on va pouvoir se lancer dans les choses sérieuses.

Compilation

Tout d'abord il nous faut une version de ssh qui supporte ce mode de fonctionnement. On la trouvez chez un certain Roumen Petrov. Bon, petite déception, il ne fournit que des patchs. A nous d'en faire un vrai ssh compilé. Pour une fois, ça va être une peu plus difficile pour les debianistes. Pour ceux qui recompilent leur ssh directement :

# à adapter à vos besoins et à votre version
$ wget http://www.roumenpetrov.info/openssh/x509-6.1.1/openssh-5.1p1+x509-6.1.1.diff.gz
$ cd openssh-source
$ zcat ../openssh-5.1p1+x509-6.1.1.diff.gz | patch -p1
$ ./configure
$ make
$ make install

Niveau :      
Résumé : uptimed

Linux est un système très stable. Tellement stable que certaines personnes font une gloire personnelle de la durée d'allumage de leurs machines.

Pour pouvoir vous vanter vous aussi auprès de vos collègues et briller dans les soirées, voici le moyen de savoir quelles ont été les différentes durées d'uptime de votre machine.

Uptimed est un simple démon disponible dans le paquet éponyme. Il suffit de l'installer. Ce démon ne fait qu'une chose et il le fait bien, il enregistre la durée depuis laquelle le système est lancé dans un fichier de logs et rend ces informations disponibles aux utilisateurs. Il est même capable de vous envoyer un mail pour vous avertir de l'atteinte d'un record.

Les utilisateurs ont accès aux meilleurs temps avec la commande uprecords :

$ uprecords

Tout ceci est bien joli et il est vrai que c'est très gratifiant d'avoir réussi à maintenir un système en fonctionnement pendant plusieurs années, voir une dizaine d'années pour certains. Mais il ne faut pas oublier une chose, la sécurité. Un noyau qui n'est jamais rebooté, ce n'est pas seulement un noyau stable, mais c'est aussi un noyau vulnérable car non mis à jour.

Alors bien sur certains argueront qu'il existe maintenant ksplice. Mais je pense que son usage reste marginal. C'est pourquoi, n'oubliez pas de mettre une sonde sur vos serveur pour surveiller les machines qui n'ont pas été rebootées depuis longtemps, c'est en fait un signe de faiblesse.

Niveau :      
Résumé : getfacl ; setfacl ; cp ; mv ; tar ; rsync ; chmod ; umask

Après avoir vu comment marchent les ACL, vous avez voulu les utiliser tous les jours. Et là vous avez besoin de quelques petites connaissances supplémentaires.

Les outils

Les outils de base ont pour la plupart bien intégré les ACL.

ls

Un ls -l ajoute un + après les droits pour vous indiquer qu'il faut utiliser getfacl pour avois plus de détail sur les droits.

Et c'est tout.

mv cp rsync

mv conserve les ACL.
cp conserve les ACL si on lui demande (avec les option -a ou -p)
rsync conserve les ACL si on lui demande (avec l'options -A)

tar

tar ne sait pas conserver les acl, il faut donc utiliser un outil différent, comme star, ou stocker les ACL dans un fichier à part et le sauvegarder avec tar. Ex:

$ getfacl -R repertoire > ACL
$ tar cvz backup.tgz repertoire ACL
$ tar xfz backup.tar.gz
$ setfacl --restore=ACL

scp

scp ne conserve bien évidemment pas les ACL, il ne conserve déjà pas les droits.

Outil perso

A vous de savoir si les script et les outils que vous avez conservent les ACL. Faites particulièrement attention aux systèmes de backup qui bien souvent utilisent tar. Si le votre ne les supporte pas, enregistrez le résultat de getfacl -R avec chacun de vos backups.

Niveau :      
Résumé : getfacl ; setfacl

ACL

Faire des groupes c'est bien, mais après quelques expériences, gérer plusieurs groupes d'utilisateurs sur une machine peut rapidement devenir un cauchemar.

Tant qu'il n'y a qu'une seule équipe, tout est jouable, on fait des groupes en fonction des droits dans cette équipe, et on attribue aux éventuels démons (apache, ftpd ... ) les groupes correspondants.

Dès qu'on se retrouve avec plusieurs équipes, une bonne gestion de la sécurité devient impossible. Supposons que vous vouliez donner accès à un fichier au groupe A et au groupe B, dans ce cas il faut faire un troisième groupe contenant les membres de A et de B. Il faut faire intervenir l'administrateur et ça devient rapidement l'horreur à maintenir.

C'est pourquoi on a inventé les ACL sur les systèmes de fichier. Grâce aux ACL, vous pourrez :

• définir plusieurs utilisateurs et groupes ayant des accès différents à un fichier donné (plus de bidouille des membres de groupes)
• définir les droits qui seront positionnés lors de la création d'un fichier dans un répertoire (plus de bidouille avec le bit suid, ni d'umask)

Les ACL c'est la fin de la bidouille dans la gestion des droits sur les fichiers !

Recette

Pour que les ACL fonctionnent chez vous, il vous faut :

• le paquet ACL qui fournit les commande setfacl et getfacl
• le support des ACL dans le système de fichier qui vous intéresse : ext2, ext3, ext4, reiserfs, jfs, xfs, nfs
• le support compilé dans le noyau : en option pour chacun des système de fichier
• le préciser lors du montage de la partition : mount -o acl ou defaults,acl dans fstab

Action

Les ACL se lisent et se modifient assez facilement : Lecture avec getfacl :

$ getfacl fichier

Modification avec setfacl :

$ setfacl -m u::rwx fichier

Il ne reste plus qu'à connaître le format des ACL, très simple : [default:]<type>:<nom>:<droits>

• type a plusieurs valeurs possibles :
  • user ou u : les droits s'appliquent à un utilisateur spécifique
  • group ou g : les droits s'appliquent à un groupe spécifique
  • other ou o : les droits s'appliquent en l'absence de correspondance (le nom est ignoré)
  • mask ou m : les droits sont les droits maximum possible sur ce fichier (le nom est ignoré)
• nom peut être vide ou être un nom d'utilisateur ou de groupe. Lorsqu'il n'est pas spécifié, il indique le propriétaire naturel "unix" du fichier
• droits est la valeur habituelle des droits tels que vous les connaissez : rwx (Read, Write, eXecute)
• si default ou d est présent, il indique que les droits seront appliqués aux fichiers créés dans ce répertoire (ne marche que pour un répertoire)

Et voila, c'est extrêmement simple non ?

Exemples

Je veux que jeremy accède en lecture à mon fichier lenna.jpg :

$ setfacl -m u:jeremy:r lenna.jpg

Je veux que les administrateurs aient accès en écriture au contenu du répertoire /usr/local/etc

$ setfacl -R -m g:admin:rw /usr/local/etc

Je veux que jeremy n'ait plus accès à mon fichier lenna.jpg

$ setfacl -x u:jeremy lenna.jpg

Je veux que tous les fichiers créés dans /tmp aient un droit de lecture pour l'utilisateur peck

$ setfacl -m d:u:peck:r /tmp

Niveau :      
Résumé : newgrp ; gpassword ; id

Sous unix, les groupes, c'est connu. Un utilisateur est nécessairement dans un groupe primaire, celui qui sert lors de la création de fichiers et répertoires. Il est aussi dans un nombre indéfini de groupes secondaires, qui servent pour les droits d'accès sur ces fichiers et répertoires.

La commande id permet de savoir quels sont vos groupes :

$ id
uid=1000(peck) gid=1000(peck) groupes=1000(peck),1002(toto)

Mais cette notion de groupe primaire n'est pas pratique si on veut créer des fichiers pour un autre groupe que le groupe primaire. Faire un chgrp à chaque nouveau fichier n'est pas des plus sympa. C'est pourquoi il existe la commande newgrp qui permet de changer de groupe primaire (celle-ci lance un nouveau shell).

$ newgrp toto
$ id
uid=1000(peck) gid=1002(toto) groupes=1000(peck),1002(toto)

Mieux, il est même possible de prendre un groupe primaire qui ne vous appartient pas. Mais cette fois un mot de passe vous sera demandé. Si vous connaissez le mot de passe le groupe deviendra votre groupe primaire (puis un groupe secondaire au prochain newgrp). Pour définir un mot de passe sur un groupe (stocké dans gshadow) :

$ gpasswd groupe

Petite bizarrerie, newgrp ne prend en compte que les groupes secondaires pour les groupes autorisés, il ne voudra donc pas vous redonner votre groupe d'origine, sauf s'il est aussi listé en groupe secondaire. Il suffit en pratique de vous déconnecter du shell pour revenire au groupe d'origine.
Remarquez que vous mettre dans le même groupe primaire et secondaire ne pose aucun problème puisqu'on le fait régulièrement lorsqu'on est branché sur un ldap.

Et voilà pourquoi il peut parfois être utile de créer des groupe alors que personne n'est dedans. Il s'agit simplement d'un mot de passe permettant de partager des fichiers sur un système.

Si vous travaillez en équipe sur des machines, pensez à cette fonctionnalité (par exemple dans vos scripts de gestion du système) cela peut vous simplifier la vie en plus de l'umask et du bit suid sur les répertoires.