Mon fixe passé de 12 à 13 me pose également des pb de suspend, avec assez fréquemment des messages pointant la feature lockdown du kernel (pourtant pas nouvelle) qui semble s'activer dès lors que le secure boot est utilisé... Et qui n'est alors pas désactivable entièrement. Cela semble s'ajouter à d'autres problèmes causés par systemd qui refuse aussi le suspend quand certains applicatifs (réseau en particulier) sont lancés, alors qu'avant c'était possible et n'a jamais posé de pb... Cela reprenait juste son cours au réveil.
Exemple de config lockdown sur un système non secure-boot:
Mais sur un système avec secure-boot on sera par défaut à "confidentiality" sans retour en arrière possible et dans ce cadre un swap non chiffré suffit à prévenir le suspend... alors que mon système n'a pas de partition swap, n'en faisant plus sur des machines 100% SSD! A croire que ce cas n'est pas prévu, si toutefois un âne n'a pas décidé que si l'utilisateur ne faisait pas de swap à l'installation on lui créait un fichier destiné à cet usage derrière son dos... A voir, mais ça fait juste hautement chier de chercher des parades à des trucs qu'on évitait sans pb avant.
En secure boot donc, tout au plus peut-on configurer via la kernel-cmdline/grub d'être, au plus permissif, à "integrity" au boot: La désactivation ne sera pas acceptée! Mais de quoi je me mêle? Si un attaquant est déjà root il aura bien plus simple à faire qu'aller lire un swap en clair merde!
Et, niveau config toujours, si sur le runtime qui suit on passe pour test à "confidentiality" via le sysfs ci dessus, effet cliquet: Pas de retour en arrière possible sur le runtime courant, obligé de rebooter.
C'est vraiment une feature assez détestable, comme tout ce qui devient impossible à régler/tester en root. Il y a un moment ou il va falloir que Linux cesse d'évoluer vers des modes prétendument "foolproof" en singeant un android et autres OS qui donnent l'impression qu'on ne possède pus réellement ce qu'on a pourtant acheté.
[^] # Re: fin du support 32 bits - meme question
Posté par lym . En réponse à la dépêche Debian GNU/Linux 13 : prêt pour le service. Évalué à 5.
Mon fixe passé de 12 à 13 me pose également des pb de suspend, avec assez fréquemment des messages pointant la feature lockdown du kernel (pourtant pas nouvelle) qui semble s'activer dès lors que le secure boot est utilisé... Et qui n'est alors pas désactivable entièrement. Cela semble s'ajouter à d'autres problèmes causés par systemd qui refuse aussi le suspend quand certains applicatifs (réseau en particulier) sont lancés, alors qu'avant c'était possible et n'a jamais posé de pb... Cela reprenait juste son cours au réveil.
Exemple de config lockdown sur un système non secure-boot:
cat /sys/kernel/security/lockdown
[none] integrity confidentiality
On est alors en "none"=lockdown inactif.
Mais sur un système avec secure-boot on sera par défaut à "confidentiality" sans retour en arrière possible et dans ce cadre un swap non chiffré suffit à prévenir le suspend... alors que mon système n'a pas de partition swap, n'en faisant plus sur des machines 100% SSD! A croire que ce cas n'est pas prévu, si toutefois un âne n'a pas décidé que si l'utilisateur ne faisait pas de swap à l'installation on lui créait un fichier destiné à cet usage derrière son dos... A voir, mais ça fait juste hautement chier de chercher des parades à des trucs qu'on évitait sans pb avant.
En secure boot donc, tout au plus peut-on configurer via la kernel-cmdline/grub d'être, au plus permissif, à "integrity" au boot: La désactivation ne sera pas acceptée! Mais de quoi je me mêle? Si un attaquant est déjà root il aura bien plus simple à faire qu'aller lire un swap en clair merde!
Et, niveau config toujours, si sur le runtime qui suit on passe pour test à "confidentiality" via le sysfs ci dessus, effet cliquet: Pas de retour en arrière possible sur le runtime courant, obligé de rebooter.
C'est vraiment une feature assez détestable, comme tout ce qui devient impossible à régler/tester en root. Il y a un moment ou il va falloir que Linux cesse d'évoluer vers des modes prétendument "foolproof" en singeant un android et autres OS qui donnent l'impression qu'on ne possède pus réellement ce qu'on a pourtant acheté.