Si j'ai bien compris le Clevis c'est un luks dont la clef se base sur le TPM?

Pour les sécu listées j'ai tout de coché sauf le U2F qui me pose trop de question non résolue. Comme par exemple tu laisses ta clef Yubi trainer sur le bureau ou connecter en permanence à l'ordi, rien n'empêche quelqu'un d'autre de valider ton 2FA à ta place donc de démarrer ta session ou ton ordi chiffré. Soit j'ai loupé un élément soit ça me parait juste bloquer que quelques scénarios d'attaque mais pas tous.

Par contre chez moi pas de SSO, on préfère pousser par Ansible l'authentification nécessaire sur les postes ou serveurs pour qu'il n'y ait pas de dépendance. Ton serveur d'authentification est chez Tartampion Cloud et ce dernier a un souci, plus personne ne peut utiliser les serveurs même chez d'autres hébergeurs, je trouve ça très moyen même avec un PCA/PRA.


Le 02/11/2021 à 18:15, Florent CARRÉ a écrit :
Wallace, je préfère l'approche du serveur, ce qui dans clevis est https://github.com/latchset/tang

La chose n'est pas parfaite mais pour certains d'usage, largement suffisant.

Sinon, tout à fait d'accord avec toi:
- password bios/EFI
- password ATA (je m'en souviens sur Thinkpad)
- password LUKS au boot
- password sur le single mode (coucou GRUB)
- password session

Ensuite, pour les plus violents:
- SSO
- PAM-U2F: https://www.prado.lt/how-to-configure-local-two-factor-authentication-with-u2f-on-ubuntu-19-10/amp
- full disk encryption:
  - old: https://sandrokeil.github.io/yubikey-full-disk-encryption-secure-boot-uefi/intro.html
  - fido2-luks: https://github.com/shimunn/fido2luks
  - additional good doc: https://wiki.archlinux.org/title/YubiKey

On Tue, Nov 2, 2021, 12:04 Wallace <wall...@morkitu.org> wrote:

    Vous avez vraiment confiance dans TPM? Qui des master keys des
    constructeurs (inévitables sur le marché US)?

    Je préfère largement qu'un utilisateur soit le seul à connaître
    son mot de passe, éventuellement set un deuxième mot de passe de
    secours pour un parc d'ordinateurs. Il le saisit au boot et on en
    parle plus. Ajouté un mot de passe pour protéger le bios et le
    changement de disque de démarrage et on est bien niveau sécurité.

    En mode zero trust je ne vois pas comment on peut faire confiance
    au TPM. Et autre avantage de cette approche, tu peux enlever le
    disque et le mettre dans un autre ordinateur, l'utilisateur repart
    directement, avec TPM il faut réinstaller obligatoirement.

    PS: pourquoi partir sur CentOS cet OS est en fin de vie depuis
    décembre 2020, autant installer directement sur une autre distro
    RPM équivalente, autant éviter une migration sous peu.

    Le 02/11/2021 à 17:32, Florent CARRÉ a écrit :
    Hello,
    Tu peux suivre la documentation officielle de red hat qui utilise
    clevis pour aussi bien utiliser un network server ou un tpm v2:

    
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening

    https://github.com/latchset/clevis

    J'espère que cela t'aidera


    On Tue, Nov 2, 2021, 08:10 Dang Herve <danghe...@gmail.com> wrote:

        Bonjour

        Je cherche à chiffrer un disque et le déverrouiller
        automatiquement au démarrage avec un TPM sous Centos.

        Quelqu'un aurait-il un guide ou un petit tutoriel
        fonctionnel? Tout ce que j'ai trouvé sur internet ne semble
        pas fonctionner ou alors je dois mal faire une étape.

        La seule chose que l'on veut faire est de se prévenir d'une
        copie de disque en dehors de notre système

        Merci

        Herve
        _______________________________________________
        Liste de diffusion du FRsAG
        http://www.frsag.org/


    _______________________________________________
    Liste de diffusion du FRsAG
    http://www.frsag.org/
    _______________________________________________
    Liste de diffusion du FRsAG
    http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à