Si j’ai bien compris il s’agit du mot de passe de la base de données de roundcube. Si tu ne veux pas stocker ce type de mot de passe en clair dans un fichier de configuration d’une application web lambda (Roundcibe ou autre), il faut que les scripts de cette application soient exécutés par un utilisateur lambda et que cet utilisateur s’authentifie auprès de MySQL via auth_socket (unix_socket avec MariaDB) et non via un mot de passe (native_mysql_password).
Merci pourcette réponse. l’utilisateur lamda doit dans ce cas être loggé dans le systeme et qu’un utilisateur de même non devra exister dans la base mysql, si j’ai bien compris ?
« loggé » ?
Il faut que ton serveur web, Apache ou Nginx, soit configuré de manière à pouvoir définir un utilisateur différent pour chaque site web, idéalement avec php-fpm et ses pools.
Ainsi tu as par exemple un utilisateur standard roundcube sans shell (/usr/sbin/nologin), donc sans possibilité de se connecter, qui exécute les scripts PHP de roundcube. Il faut avoir ce même utilisateur dans MariaDB qui a les droits uniquement sur la base de données de roundcube et qui s’authentifie via unix_socket.
Corrigez-moi si j’écris une bêtise, mais il me semble d’une part que ce n’est possible qu’avec une base de données locale, et d’autre part cela n’empêche pas l’accès à la base de données en cas de vol du disque.
Avant de chercher des solutions, il faut définir le vrai besoin.
Certes, répondre à un besoin n’est pas toujours équivalent à répondre à une demande.
La réponse technique plus haut est très intéressante car elle résout le problème pour un systeme en fonctionnement. Mon soucis est si pour une raison ou une autre, le disque sera branché dans une autre machine alors tout devient accessible.
@PascalHambourg : Oui et oui 
Rien ne peut protéger les données en cas d’accès physique, ou vol de disque, à part le chiffrement.
Je pensais bêtement à un serveur hébergé dans un data center où l’accès physique est très restreint.
Désolé si je n’ai pas compris le besoin réel.
Je ne connais qu’une protection des données contre le vol du support : le chiffrement. Mais se pose le problème du déchiffrement au démarrage du système.
Non, c’est le besoin réel qui n’était pas clairement exprimé (comme souvent).
Désolé si le besoin réel n’était pas suffisament bien exprimé. (En fait, je l’avais exprimé dans un précèdent message « //www.debian-fr.org/t/cloner-un-dd-non-cryppte-sur-un-dd-chiffre-avec-luks/82433) » mais comme je n’avais pas reçu de réponse, alors j’ai essayé de faire differement)
Habituellement je chiffre avec luks avant d’utiliser le disque . Mais là, le serveur « tourne » depuis une dizaine d’années avec beaucoup de programmes. Je ne sais pas si je peux le copier (j’aimerai dire cloner) sur un disque neuf et crypté
Je n’avais pas vu ce sujet précédent. De toute façon c’est loin d’être aussi simple, on ne peut pas juste « cloner » un système sur un disque chiffré.
Je vais devoir partir sur une nouvelle installation, puis installer les services un par un. Je suppose qui’il faille exporter/importer les bases et adapter dans certains cas les fichiers de configuration qui seraient devenus obsolètes…etc. Bien sur, je ne touche pas au disque dur actuel mais je m’achette un nouveau. Ce qui me permet de remettre rapidement le serveur en route dans sa dernière bonne config, en cas de necessité.
La version actuelle est stretch 32 bits, issue de mise à jour en mise à jour, depuis Lenny.
A l’époque, javais fais le choix d’une version 32 bit puisque la carte mère est limitée à 4GO de RAM (2^32=4GO)
Je pense partir sur un SSD, le crypter puis installer dessus Debian Buster 32 ou 64 bits. Y a t-il des précautions particulières à prendre par rapport au SSD ? swap hors LUKS ?
-Os 32 ou 64 bits, y a t-il un avantage de l’un par rapport à l’autre, en termes de support/mises à jour ou disponibillité des programmes ?
Je n’ai pas écrit que c’était impossible de cloner un système vers un disque chiffré, mais seulement que c’était compliqué. Il y a une multitude de petites opérations qui sont normalement prises en charge par l’installateur et qu’il faut réaliser manuellement, sans en oublier.
Une autre possibilité plus simple consiste à ne chiffrer que les données et à laisser le système en clair en les séparant dans des volumes distincts.
Tu avais commis la même erreur que celles et ceux qui ne connaissent pas la gestion de la mémoire par un noyau Linux 32 bits. D’abord, 4 Gio représente l’espace adressable et non la RAM. Ensuite, il faut distinguer deux espaces d’adressage :
-
L’espace d’adressage physique qui est occupé non seulement par la RAM système mais aussi par l’adressage des périphériques système (carte graphique et sa mémoire, contrôleurs disque ou réseau et leurs tampons…). C’est pourquoi la RAM maximum disponible est inférieure à 4 Gio, typiquement entre 3 et 3,5 Gio, mais parfois seulement 2 Gio, le reste étant alloué à l’adressage des périphériques système. L’extension d’adressage physique PAE permet d’accéder à l’espace d’adressage au-delà de 4 Gio (jusqu’à 64 Gio) mais c’est au prix d’une couche supplémentaire.
-
L’espace d’adressage virtuel (mémoire virtuelle) dans lequel le noyau et les processus s’exécutent. La gestion de la mémoire d’un noyau Linux 32 bits le divise en deux : 3 Gio pour le processus et 1 Gio pour le noyau. Cela implique d’une part qu’un processus 32 bits ne peut pas utiliser plus de 3 Gio de mémoire virtuelle (quelles que soient les quantités de RAM et de swap disponibles), et d’autre part qu’au delà de 1 Gio de RAM, le noyau doit la diviser en mémoire « basse » (lowmem, jusqu’à un peu moins de 1 Go), mappée en permanence donc accessible immédiatement, et mémoire « haute » (highmem, le reste) qui doit être mappée à la demande pour y accéder donc accessible moins rapidement. En résumé : la gestion de la mémoire par un noyau 32 bits n’est plus optimale au-delà de 1 Gio de RAM.
Voici un exemple de découpage lowmem/highmem extrait de /proc/meminfo avec 1,5 Gio de RAM :
MemTotal: 1550600 kB
HighTotal: 664456 kB
LowTotal: 886144 kB
De plus, l’architecture 64 bits n’apporte pas seulement une meilleure gestion de la mémoire mais aussi plus de registres, et des tailles de registres plus grandes pour les opérations sur les entiers, de nouvelles instructions… Ce n’est pas parce que le système est 32 bits qu’il n’a pas besoin de manipuler des données de taille plus grande, par exemple pour le stockage sur disque dont la taille est typiquement bien supérieure à 4 Gio. Un noyau 64 bits est plus performant pour traiter ces données.
Enfin, l’architecture 64 bits est devenue l’architecture principale de développement, et il commence à arriver des bugs qui affectent spécifiquement l’architecture 32 bits. Par exemple la version i386 de gzip dans Stretch est affectée par un bug de compilation qui la rend incompatible avec les paramètres de sécurité par défaut d’udev (ce qui empêche notamment l’application de la police de caractères définie dans les consoles virtuelles tty1-6). Egalement les bugs et les failles de sécurité spécifiques aux processeurs (Spectre et compagnie) peuvent être moins vite corrigés pour l’architecture 32 bits.
Ce n’est pas encore le cas de Debian, mais certains distributeurs de binaires ne fournissent plus de versions 32 bits de leurs programmes.
L’installateur ne supporte pas /boot chiffré, donc si la racine est chiffrée il faut obligatoirement créer une partition /boot séparée non chiffrée.
Il y a 3 possibilités pour le swap :
-
swap non chiffré (attention car peut contenir des données sensibles)
-
swap dans un volume chiffré « avec clé aléatoire » (plain dm-crypt, sans LUKS) recréé à chaque démarrage donc incompatible avec l’hibernation ; pas très bien géré par l’installateur Debian et très dangereux avec plusieurs disques (risque d’écraser une partition d’un autre disque au démarrage), donc à éviter comme la peste à mon avis
-
swap dans un volume chiffré LUKS comme le reste
Si tu as plusieurs « volumes » chiffrés avec LUKS (par exemple racine, swap, /var…), deux possibilités :
- créer des volumes chiffrés distincts pour chacun, dont il faudra taper les passphrases au démarrage ; compliqué et fastidieux
- créer un unique volume chiffré avec LUKS utilisé comme volume physique LVM et créer des volumes logiques à l’intérieur (ce qui est proposé en partitionnement assisté)
1 J'aime
Merci beaucoup pour cette réponse riche et détaillée. (Si je comprends bien, fini l’époque des programmes en assembleur sur des processeurs 8/16 bits avec les 4 registres généraux + quelques uns suplémetaires ?:)).
Pour mon serveur, la sécurité prime sur la performance, donc si je réinstalle linux, je préviliegerai une version 64bits. Si non, je le mets à jour vers du 64 bits, j’imagine que c’est encore une tache compliquée.
Je suis intéressé de tenter cette manip en premier, avec le swap dans une partition ou un volume logique ( si j’utiluse LVM), de type LUKS).
J’ai fait cela avant hier en attendant de trouver une solution plus complete. J’ai crypté une partition
dans laquelle j’ai mis /home, les mails et les data owncloud.
Le systeme en clair boot sans ses partitions, puis à la fin je me connecte via ssh pour lancer à la main un petit programe qui fini le travail. (décrypte et monte la partition en question, decrypte et monte un RAID1 et lance backuppc, syslog-ng). Il y a des declarations « unix-dgram » dans le fichier de conf de syslog-ng, pour avoir les logs du chroot jail via des sockets et ces sockets sont dans /home/users.
ça devient compliqué, je préfère avoir un systeme entièrement crypté et rentrer le mot de passe via ssh au chargement de initramfs.
Bonjour,
J’aimerai copier le rootfs non crypté d’un serveur sur un autre disque dur vide et crypté LUKS. Pouvez-vous me proposer des instructions à faire, svp ?
Je vais cloner avec dd le disque dur du serveur sur un SSD (pour commencer, j’essaye quand même de ne pas confondre les deux ). Ensuite, je ferai toutes les manips sur le SSD. je planque l’original.
Le SSD est partitionné en 2. Sa premiere partition est le clone du serveur et sa deuxième partition est cryptée avec LUKS et est vide. c’est sur cette dernière que je souhaite copier le rootfs.
En gros, je pense booter sur une clé USB, copier le rootfs et faire un grup update, mais je ne sais pas si ça marche ?
Ce n’est pas très clair. Comment exactement est réalisé le clonage ?
Un clonage de disque à disque crée des partitions identiques sur les deux disques. Je ne comprends pas comment un disque peut être cloné dans une partition.
Si c’est avec une commande du genre
dd if=/dev/sda of=/dev/sdb1
alors ça ne marchera pas.
D’autre part, que devriendra cette partition après transfert dans le volume chiffré ? Ce sera de l’espace perdu.
Bonjour,
Le rootfs du serveur fonctionnel (linux Stretch 32bits) est stocké dans sda1 (disque dur mécanique). J’ai donc cloné la partition sda1 sur la partition sdb1 du SSD, avec « pv -tpreb /dev/sda1 | dd of=/dev/sdb1 bs=4M », puis à la fin, j’ai lancé liloconfig, puis lilo.
Ensuite, j’ai débranché et mis de coté le disque dur mécanique et démarré la machine sur le SSD. Le clone fonctionne normalement. (noms de partitions au lieu des UUID dans fstab)
Je ne suis pas spécialiste, c’est pourquoi je prends des précautions en clonant le serveur, avant de le mettre à jour vers Debian Buster, ce qui me permet de revenir en arrière en cas de problèmes.
Enfin, j’ai mis à jour Stretch–>Buster, en remplaçant ces noms dans sources.list puis (apt update, upgrade et dist-upgrade), puis monté la partition sda3 cryptée qui contient « /home » pour que dovecot et syslog–ng puissent fonctionner…
A présent, la partion sda1 du SSD contient le serveur de réference qui est Buster 32 bits. Je vais donc à nouveau la copier sur l’espace disponible non utilisé dans le SSD (qui s’appelera bientôt sda4). Mais cette fois-ci, sda4 sera cryptée. Je ne sais pas comment faire au mieux cette copie, je tente avec un tar, aures…?
Puis se posera le problème de rentrer la passe phrase au boot. J’ai vu des tutos avec dropbear permettant de le faire à distance…
Tu veux dire les étiquettes (LABEL) ou les noms de périphérique (/dev/sd*) ?
Dans le second cas c’est une très mauvaise idée car les noms de périphériques /dev/sd* ne sont pas stables. D’autre part c’est inutile car l’UUID et le LABEL sont copiés lors du clonage.
Comme tu veux, un volume chiffré s’utilisant comme une partition. Tu peux faire un clonage avec dd si la taille du volume chiffré est supérieure ou égale à celle de la partition d’origine. Le plus dur reste à faire : effectuer les modifications nécessaires dans /etc/fstab, /etc/crypttab, l’initramfs, le chargeur d’amorçage… pour que le système puisse démarrer avec la racine chiffrée.
D’autre part il faudra transférer le contenu de /boot dans une partition séparée non chiffrée.
La partition de destination sda4 est cryptée, si je fais un dd de sda1 non cryptée sur sda4 cryptée, alors dd ecrasera aussi son entête luks, non ? puisque il copie bloc par bloc de cylindres (peut importe la manière ou sont ordonnés les ‹ 0 › et ‹ 1 ›). Peut-on demander à dd de démarer à un certain offset ?
Bonjour
Oui, en lecture comme en écriture.
N’hésite pas à consulter la page man de la commande dd :
man dd
J’ai écrit « un volume chiffré » (/dev/mapper/nom_du_volume), pas la partition chiffrée qui lui sert de support.
Surtout, il copie en clair sans chiffrement. Pour que les données soient chiffrées, il faut les écrire dans le volume chiffré.
@MicP
C’est pas bien de conforter les gens dans leur erreur.
Ok, merci