Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
22 mars 2016

htmlpdflatexmanmd




dm-crypt

dm-crypt

Chiffrement transparent des périphériques block

   la cible crypt de Device-Mapper fournis un chiffrement transparent des périphériques blocks utilisant l'API crypto du kernel

Paramètres

cipher Algorithme de chiffrement et un mode de génération IV optionel (ex: des, aes-cbc-essip:sha256, twofish-ecb). /proc/crypto contient les modes crypto supportés
key Clé utilisée pour le chiffrement. Encodé en hexadécimal.
keycount Mode compatibilité multi-clé. On peut définis keycount clé et les secteurs sont chiffrés en accord avec leur offset (le secteur 0 utilise key0, etc.)
iv_offset L'offset IV est un compteur de secteur qui sont ajoutés au numéro du secteur avant de créer l'IV
device_path Périphérique qui est utilisé comme backend et contient la donnée chiffrée.
offset Secteur de départ dans le périphérique où les données chiffrée commencent
#opt_params Nombre de paramètres optionnels.

Paramètres optionnels

allow_discards Block discard request passé au périphérique crypté. Défaut: ignore ces requêtes
same_cpu_crypt Effectue le chiffrement en utilisant le même cpu que l'IO qui l'a émis.
submit_from_crypt_cpus Désactive l'écriture offload dans un thread séparé après le chiffrement. L'écriture bénéficie à CFQ, mais peut dégrader les performances dans certains cas.

Scripts d'exemple

LUKS (Linux Unified Key Setup) est la manière préférée pour définir le chiffrement de disque avec dm-crypt en utilisant l'utilitaire cryptsetup
[[
#!/bin/sh
# Crée un périphérique crypto avec dmsetup
dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
]]
    
[[
#!/bin/sh
# Crée un périphérique en utilisant cryptsetup et LUKS avec le chiffrement par défaut:
cryptsetup luksFormat $1
cryptsetup luksOpen $1 crypt1
]]

^
31 mars 2016

htmlpdflatexmanmd




inotify

inotify

Surveillance des événements des systèmes de fichier

   inotify est contrôlé par un jeu de 3 appels système et d’un fichier I/O normal retourné sur un descripteur de fichier.

inotify_init(2) Créé une instance inotify et renvoie un descripteur de fichier se référant à cette instance inotify. inotify_init1(2) est similaire mais offre un argument flags qui fournis des fonctionnalités supplémentaires.
inotify_add_watch(2) Manipule la liste de surveillance associée à une instance inotify. Chaque élément indique le chemin d'un fichier ou d'un répertoire avec un ensemble d'événements à surveiller.
inotify_rm_watch(2) Retire un élément d'une liste de surveillance inotify

Pour déterminer quels événements ont lieu, une application lit le descripteur de fichier inotify avec read(2). Chaque lecture réussie renvoie un tampon contenant une ou plusieurs structures suivantes:
struct inotify_event {
    int wd; /*Descripteur de surveillance*/
    uint32_t mask; /*Masque d'événements*/
    uint32_t cookie; /*Cookie unique d'association des événements (pour rename(2))*/
    uint32_t len; /*Taille du champ name*/
    char name[]; /*Nom optionnel terminé par un nul*/
};

wd identifie l'élément de surveillance
mask contient des bits décrivant l'événement
cookie entier unique qui relie les événements. Utilisé uniquement pour les événements de renommage
len Compte tous les octets de name, incluant les caractères nuls.

Événements inotify

IN_ACCESS accès au fichier
IN_ATTRIB Modification des métadonnées, ex les permissions, horodatages, attributs étendus, compteur de liens, UID ou GID.
IN_CLOSE_WRITE Fichier ouvert en écriture fermé
IN_CLOSE_NOWRITE Fichier non ouvert en écriture fermé
IN_CREATE Fichier ou répertoire créé dans le répertoire surveillé
IN_DELETE Fichier ou répertoire supprimé dans le répertoire surveillé
IN_DELETE_SELF Fichier ou répertoire surveillé supprimé ( ou déplacé dans un autre système de fichier)
IN_MODIFY Fichier modifié
IN_MOVE_SELF Fichier ou répertoire surveillé déplacé
IN_MOVED_FROM Généré pour le répertoire contenant l'ancien nom quand un fichier est renommé
IN_MOVED_TO Généré pour le répertoire contenant le nouveau nom quand un fichier est renommé
IN_OPEN Fichier ouvert
IN_MOVE Équivalent à IN_MOVED_FROM | IN_MOVED_TO
IN_CLOSE Équivalent à IN_CLOSE_WRITE | IN_CLOSE_NOWRITE
IN_DONT_FOLLOW e pas déréférencer pathname s'il s'agit d'un lien symbolique
IN_EXCL_UNLINK Ne génère pas d'événements pour certaines entrées après leur suppression du répertoire surveillé
IN_MASK_ADD Ajouter des événements au masque de surveillance de ce fichier s'il existe déjà (au lieu de remplacer le masque)
IN_ONESHOT Surveiller pathname jusqu'au premier événement, puis le supprimer de la liste de surveillance
IN_ONLYDIR Ne surveiller pathname que si c'est un répertoire
IN_IGNORED Le surveillant a été retiré explicitement au automatiquement
IN_ISDIR Le sujet de cet événement est un répertoire
IN_Q_OVERFLOW File des événements surchargé
IN_UNMOUNT Le système de fichiers contenant l'objet surveillé a été démonté
^
25 mai 2017

htmlpdflatexmanmd




keys.txt

keys.txt

Service de rétention de clé kernel

   Ce service autorise les clé cryptographiques, jetons d'authentification, mappage d'utilisateur inter-domaine, et similaire d'être mis en cache dans le kernel pour utiliser les systèmes de fichier et d'autres services kernel.

   Les portes-clés sont permis; ce sont des type spéciaux de clé qui peuvent maintenir des liens vers d'autres clés. Chaque processus a 3 souscription de porte clé standard qu'un service peut utiliser pour trouver des clés.

   Le service de clé peut être configuré ou activé avec "Security options"/"Enable access key retention support" (CONFIG_KEYS)

Présentation

   Dans ce contexte, les clés représentent des unités de données cryptographiques, des jetons d'authentification, porte clé, etc. Ils sont représenté dans le kernel pas la structure key.

   Chaque clé a un nombre d'attribut:

- un numéro de série
- un type
- une description
- des informations de contrôle d'accès
- une date d'expiration
- Un payload
- l'état

   Chaque clé reçois un numéro de série du type key_serial_t qui est unique pour la durée de vie de cette clé. Tous les numéros de série sont des entier 32bits positifs. Les programmes userspace peuvent utiliser le numéro de série d'une clé comme moyen d'y accéder, sujet à vérification des permissions.

   Chaque clé est d'un type définis. Les types doivent être enregistrés dans le kernel par un service kernel (tel qu'un système de fichier) avant que des clés de ce type puissent être ajoutées ou utilisées. Les programmes userspace définissent les nouveaux type directement. Les types de clé sont représentés dans le kernel par la structure key_type. cela définis un nombre d'opérations qui peuvent être effectuées sur une clé de ce type.

   Chaque clé a une description, qui devrait être une chaîne affichable. Le type de clé fournis une opération pour effectuer une correspondance entre la description dans un cré et une chaîne critère

   Chaque clé peut être définie pour expirer à un moment donné par la fonction d'instantiation du type. Les clés peuvent être immortelles.

   Chaque clé peut avoir un payload. C'est la quantité de données qui représente la clé. Dans le cas d'un porte-clé, c'est une liste de clés qui sont liées au trousseau; dans le cas d'une clé définie par l'utilisateur, c'est un blob de donnée arbitraire Ce payload n'est pas requis, et le payload peut, en fait, être simplement stocké dans la structure de clé elle-même

   Similairement, quand le userspace souhaite lire le contenu de la clé, si permis, une autre opération de type de clé sera appelée pour convertir le payload attaché à la clé en un blob de donnée.

   Chaque clé peut être dans un des états de base suivant:

- non-instancié. La clé existe, mais n'a pas de données attachée. Les clés demandée depuis le userspace sont dans cet état
- instancié: C'est l'état normal. La clé est formée, et a des donnée attachées
- Négative. C'est un état relativement court. La clé agit comme une note disant que l'appel précédent du userspace a échoué, et agit comme un accélérateur de recherche de clé. une clé négative peut être mise à jours vers un état normal.
- expiré. Les clé ont dépassés la durée de vie définie. Une clé expirée pour être mise à jours pour revenir à un état normal
- révoqué. Une clé est placée dans cet état par une action userspace.
- dead. Le type de clé a été désenregistré

Vue générale du service de clés

   Le service de clé fournis des fonctionnalité:

           Le service de clé définis 3 types de clé spéciaux

                keyring Keyring sont des clé spéciales qui contiennent une liste d'autres clé.
                user Une clé de ce type a une description et un payload qui sont des blobs arbitraires de données. Ils peuvent être manipulés par le userspace et ne sont pas prévus pour être utilisés par les services kernel
                logon Comme une clé user, une clé logon a un payload qui est un blob de données arbitraire. Il est prévue comme un emplacement pour stocker des secrets qui sont accessible au kernel mais pas aux programmes userspace

        Chaque processus souscrit à 3 keyrings: un keyring spécifie au thread, un keyring spécifique au processus, et un keyring spécifique à une session.
        Chaque user ID résident dans le système maintient 3 keyrings spéciaux: un spécifique à l'utilisateur et un spécifique à la session utilisateur.
        Chaque utilisateur a 2 quotas avec lesquel les clés qu'ils possèdent sont suivis. Une limite le nombre total de clé et de trousseaux, et l'autre limite la quantité totale d'espace qui peut être consommé par les descriptions et payload
        Il y a une interface d'appel système par laquelle les programmes peuvent créer et manipuler les clé et trousseaux.
        Il y a une interface kernel par laquelle les services peuvent enregistrer des type et rechercher des clés
        Il y a une manière pour qu'une recherche faite depuis le kernel revienne au userspace pour demander une clé qui ne peut pas être trouvée dans un trousseau de processus
        Un système de fichier optionnel est disponible via lequel la base de clé peuvent vue et manipulée

Permissions d'accès aux clés

   Les clé ont un propriétaire, un groupe d'accès, et un masque de permission. La masque a jusqu'à 8 bit chacun pour le processeur, utilisateur, groupe et les autres accès. Seul six de chaque jeu de 8bits sont définis. Ces permissions sont:

        View Permet de voir une clé ou un trousseau, incluant le type et description
        Read Permet de voir une le payload d'une clé, ou la liste des clé liées au trousseau
        Write Permet d'instancier un payload de clé ou de le mettre à jours, ou d'ajouter/supprimer un lien vers un trousseau.
        Search Permet de rechercher un trousseau et des clés.
        Link Permet de lier une clé ou un trousseau. Pour créer un lien d'un trousseau vers une clé, un processus doit avoir la permission Write sur le trousseau, et la permission Link sur la clé
        Set Attribute Permet de changer le masque de permissions

Support SELinux

   La classe de sécurité "key" a été ajoutée à SELinux pour que le contrôle d'accès puisse être appliqué aux clés créées dans divers contextes. Actuellement, toutes les permissions de base ci-dessus sont fournis dans SELinux, SELinux est simplement invoqué une fois les vérification de permissions de base effectuées.

   La valeur du fichier /proc/self/attr/keycreate influence le labéling des clés créées. Si le contenu de ce fichier correspont à un contexte de sécurité SELinux, la clé obtiendra ce contexte, sinon, la clé obtiendra le contexte courant de la tâche qui a invoqué la création de la clé. Les tâches doivent données explicitement les permissions à assigner à un contexte particulier aux clé nouvellement créées, en utilisant la permission "create" dans la classe de sécurité key.

   Les trousseaux par défaut associés avec les utilisateurs sont labélisés avec le contexte par défaut de l'utilisateur si et seulement si les programmes login ont été configurés correctement pour initialiser keycreate durant le processus de login. Sinon, il vont être labélisé avec le contexte du programme login lui même.

   Noter, cependant, que les trousseaux par défaut associés avec l'utilisateur root sont labélisés avec le contexte kernel par défaut, vu qu'ils sont créés très tôt dans le processus de boot, avant que root ait une chance de se connecter.

   Les trousseaux associés avec de nouveaux threads sont chacun labélisés avec le contexte de leur thread associés, et les trousseaux de session et de processus sont gérés de manière similaire.

Nouveaux fichiers procfs

   2 fichiers ont été ajoutés à procfs par lesquels un administrateur peut trouver le status du service de clé:

/proc/keys Liste les clé qui sont actuellement lisibles par la tâche lisant le fichier, en donnant les informations sur le type, description et permissions. Les clés incluse dans la liste sont celles dont la permission View est donné au processus qui lit le fichier. Noter que les vérifications de sécurité LSM sont effectuées, et peuvent filtrer les clés que le processus courant n'est pas autorisé à voir.


        Le contenu ressemble à:
SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY
00000001 I----- 39 perm 1f3f0000 0 0 keyring _uid_ses.0: 1/4
00000002 I----- 2 perm 1f3f0000 0 0 keyring _uid.0: empty
00000007 I----- 1 perm 1f3f0000 0 0 keyring _pid.1: empty
0000018d I----- 1 perm 1f3f0000 0 0 keyring _pid.412: empty
000004d2 I--Q-- 1 perm 1f3f0000 32 -1 keyring _uid.32: 1/4
000004d3 I--Q-- 3 perm 1f3f0000 32 -1 keyring _uid_ses.32: empty
00000892 I--QU- 1 perm 1f000000 0 0 user metal:copper: 0
00000893 I--Q-N 1 35s 1f3f0000 0 0 user metal:silver: 0
00000894 I--Q-- 1 10h 003f0000 0 0 user metal:gold: 0

        I Instancié
        R Révoqué
        D Mort
        Q Contribut au quota de l'utilisateur
        U En construction
        N Clé négative

/proc/key-users Ce fichier liste les données pour chaque utilisateur qui a au moins une clé dans le système. De telles données incluent les informations de quota et des statistiques:


        [root@andromeda root]# cat /proc/key-users
0: 46 45/45 1/100 13/10000
29: 2 2/2 2/100 40/10000
32: 2 2/2 2/100 40/10000
38: 2 2/2 2/100 40/10000

        ‹UID› User ID
        ‹usage› Structure refcount
        ‹inst›/‹keys› Nombre total de clés et le nombre instanciées
        ‹key›/‹max› Quota - compteur de clé
        ‹bytes›/‹max› Quota - taille de clé

   4 nouveaux fichiers sysctl ont été ajoutés également pour contrôler les limites de quota:

/proc/sys/kernel/keys/root_maxkeys Nombre maximum de clés que root peut posséder
/proc/sys/kernel/keys/root_maxbytes Taille maximum en octets que root peut stocker dans ces clés
/proc/sys/kernel/keys/maxkeys Nombre total de clé qu'un utilisateur peut posséder
/pro/sys/kernel/keys/maxbytes Taille maximum en octets qu'une utilisateur peut stocker dans ces clés

Garbage collector

   Les clés morets (pour lesquelles le type a été supprimé) sont automatiquement unlinked des trousseaux et supprimés dès que possible par un collector en tâche de fond.

Similairement, les clé révoquées et expirées sont collectées, mais seulement au bout d'un certain temps. Ce délai est définis en secondes dans:
/proc/sys/kernel/keys/gc_delay
^
22 mars 2016

htmlpdflatexmanmd




module-signing

module-signing

Signature des modules kernel

Présentation

   La facilité de signature de module kernel signe cryptographiquement les modules durant l'installation et vérifie la signature au chargement des modules. Cela augmente la sécurité de kernel en interdisant le chargement des modules non-signés ou les modules signés avec une clé invalide. La signature de module augmente la sécurité en rendant le chargement de code malicieux plus dur dans le kernel. La vérification de la signature est fait par le kernel donc il n'est pas nécessaire d'avoir de clé de confiance dans l'espace utilisateur.

   Cette facilité utilise les certificats X.509 pour encoder les clé publiques. Les signature ne sont pas encodées par un type standard. La facilité supporte actuellement seulement RSA. Les algorithmes de hashage qui peuvent être utilisée sont SHA-1, SHA-224, SHA-256, SHA-384, et SHA-512.

Configuration

   La facilité de signature de module est activée par la section "Enable Loadable Module Support" de la configuration du kernel et en activant CONFIG_MODULE_SIG. Il y a quelques options disponibles:

Require modules to be validly signed CONFIG_MODULE_SIG_FORCE - spécifie le comportement du kernel lorsque la signature d'un module ne peut pas être vérifiée. off, autorise les module non-signés ou non valides, restrictive impose une signature valide.
Automatically sign all modules CONFIG_MODULE_SIG_ALL - Signe les modules automatiquement durant la phase modules_install. À off, les modules doivent être signés manuellement avec scripts/sign-file
Which hash algorithm should modules be signed with? Présente un choix d'algorithmes de hashage pour signer les modules
File name or PKCS#11 URI of module signing key CONFIG_MODULE_SIG_KEY - Définir cette option à une valeur différente que le défaut "certs/signing_key.pem" désactive l'autogénération des clés de signatures. Cette chaîne devrait identifier un fichier contenant une clé privée et son certificat correspondant au format PEM, ou - sur les système où OpenSSL ENGINE pkcs11 est fonctionnel
Additional X.509 keys for default system keyring CONFIG_SYSTEM_TRUSTED_KEYS - Définis un fichier PEM contenant des certificats additionnels qui seront inclus dans le système par défaut.

Générer les clés

   Une paire de clé cryptographique est requise pour générer et vérifier les signatures. Une clé privée est utilisée pour générer une signature et la clé publique correspondante est utilisée pour la vérifier. La clé privée est seulement nécessaire durant le build, et peut être supprimée ensuite. La clé publique est embarquée dans le kernel.

   Dans des conditions normales, CONFIG_MODULE_SIG_KEY est inchangé de son défaut, le build génère automatiquement une nouvelle clé en utilisant openssl s'il n'existe pas de fichier certs/signing_key.pem. certs/x509.genkey est également généré et contient les paramètres openssl.

Par défaut la section req_distinguished_name contient:
[ req_distinguished_name ]
#O = Unspecified company
CN = Build time autogenerated kernel key
#emailAddress = unspecified.user@unspecified.company

La taille de clé est également définie avec:
[ req ]
default_bits = 4096

Il est également possible de générer manuellement les fichiers avec le fichier x509.genkey:
openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 -config x509.genkey -outform PEM -out kernel_key.pem -keyout kernel_key.pem

Clés publiques dans le kernel

   Le kernel contient un jeu de clé publiques qui peuvent être vues par root (cat /proc/keys).

   Au delà la clé publique générée spécifiquement pour la signature de module, des certificats additionnels peuvent être fournis au format PEM référencés par l'option kernel CONFIG_SYSTEM_TRUSTED_KEYS.

   De plus, le code peut prendre des clés publiques depuis un stockage hardware et les ajouter (ex: depuis une base de clé UEFI)

Finalement, il est possible d'ajouter des clé publiques en faisant:
keyctl padd asymmetric "" [.system_keyring-ID] ‹[key-file]›

   Noter cependant que le kernel ne permet que d'ajouter des clés dans .system_keyring s'ils sont signés par une clé déjà présente dans le .system_keyring au moment où elle est ajoutée.

Signer des modules manuellement

   Pour signer manuellement un module, utiliser le script sign-file. Ce script nécessite 4 arguments: l'algorithme de hashage, le nom de la clé privée ou une URI PKCS#11, la clé publique et le module à signer.

exemple:
scripts/sign-file sha512 kernel-signkey.priv kernel-signkey.x509 module.ko

   L'algorithme de hashage utilisé ne doit pas correspondre à celui configuré, mais l'algorithme utilisé doit être compilé dans le kernel ou un module chargeable. Si la clé privée nécessite une passphrase ou PIN, il peut être fournis dans la variable d'environnement $KBUILD_SIGN_PIN

Modules signés et stripping

   Un module signé a une signature numérique simplement ajouté à la fin. La chaîne '~ Module signature appended~ .' à la fin diu fichier du module confirme qu'une signature est présente mais ne confirme pas que la signature est valide.

   Les modules signés sont embarqué comme signature hors du conteneur ELF. Donc, ils ne peuvent plus être stripped une fois la signature calculée. Noter que tout le module est le payload signé, incluant les informations de debug présents au moment de la signature.

Charger des modules signés

   Les modules sont chargés avec insmod, modprobe, init_module() ou finit_module(), exactement comme pour les modules non-signés et aucun traitement n'est fait dans l'espace utilisateur. La vérification de la signature est entièrement faite dans le kernel

Signatures non-valides et modules non-signé

   Si CONFIG_MODULE_SIG_FORCE est activé ou enforcemodulesig=1 est fournis au kernel, le kernel va seulement charger les modules signés et valides pour lequel il possède une clé publique. Un module pour lequel le kernel a une clé, mais qui prouve qu'une signature ne correspond pas ne sera pas chargé. Tout module dont la signature n'est pas lisible sera rejeté.

Administrer/protéger la clé privée

   Vu que la clé privée est utilisée pour signer les modules, les virus et malware peuvent l'utiliser pour signer des modules et compromettre l'OS. La clé privée doit être soit détruite, soit placée dans une emplacement sûre et non possédé dans le nœud root du kernel.