Why is my LUKS partition mounted without asking for a passphrase?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
6
down vote

favorite
1












On my system, I have two encrypted disks:



  1. crypt containing the root partition of raspbian stretch

  2. usb-crypt is an external usb disk. LVM is used on that disk.

Both disks are protected using the same passphrase, but the master key is different according to "cryptsetup luksDump". Neither of the two disks are configured using a key file (only one key slot is used for each LUKS container).



When the system is booting, it is asking for the passphrase of "crypt", but usb-crypt is automatically mounted without asking for a passphrase. Note: I started with an unencrypted root partition, and with that setup, I was asked for the passphrase of usb-crypt during boot.



Here is the detailed setup:



$ sudo dmsetup ls --target crypt
crypt (254, 0)
usb-crypt (254, 1)

$ sudo cat /etc/fstab
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mapper/crypt / ext4 defaults,noatime 0 1
# ...
UUID=b9fb061f-0877-4d2c-bd3c-9c155b8f88a5 /mountpoint ext4 rw,auto 0 0

$ sudo cat /etc/crypttab
# <target name> <source device> <key file> <options>
crypt /dev/mmcblk0p2 none luks
usb-crypt UUID=31fb8df7-6148-4408-90a2-93b8ec752fa0 none luks


While having only to type the passphrase once is convenient, I am surprised seeing this behaviour. I'd have expected to be asked for both passphrases.



Is this related to using the same passphrase on both disks? Or is the master key of the usb disk automatically saved somewhere in the encrypted root partition of "crypt"? I'd appreciate if someone could explain what's going on here and maybe give some hints to relevant log files, etc.



Thanks in advance!







share|improve this question
























    up vote
    6
    down vote

    favorite
    1












    On my system, I have two encrypted disks:



    1. crypt containing the root partition of raspbian stretch

    2. usb-crypt is an external usb disk. LVM is used on that disk.

    Both disks are protected using the same passphrase, but the master key is different according to "cryptsetup luksDump". Neither of the two disks are configured using a key file (only one key slot is used for each LUKS container).



    When the system is booting, it is asking for the passphrase of "crypt", but usb-crypt is automatically mounted without asking for a passphrase. Note: I started with an unencrypted root partition, and with that setup, I was asked for the passphrase of usb-crypt during boot.



    Here is the detailed setup:



    $ sudo dmsetup ls --target crypt
    crypt (254, 0)
    usb-crypt (254, 1)

    $ sudo cat /etc/fstab
    /dev/mmcblk0p1 /boot vfat defaults 0 2
    /dev/mapper/crypt / ext4 defaults,noatime 0 1
    # ...
    UUID=b9fb061f-0877-4d2c-bd3c-9c155b8f88a5 /mountpoint ext4 rw,auto 0 0

    $ sudo cat /etc/crypttab
    # <target name> <source device> <key file> <options>
    crypt /dev/mmcblk0p2 none luks
    usb-crypt UUID=31fb8df7-6148-4408-90a2-93b8ec752fa0 none luks


    While having only to type the passphrase once is convenient, I am surprised seeing this behaviour. I'd have expected to be asked for both passphrases.



    Is this related to using the same passphrase on both disks? Or is the master key of the usb disk automatically saved somewhere in the encrypted root partition of "crypt"? I'd appreciate if someone could explain what's going on here and maybe give some hints to relevant log files, etc.



    Thanks in advance!







    share|improve this question






















      up vote
      6
      down vote

      favorite
      1









      up vote
      6
      down vote

      favorite
      1






      1





      On my system, I have two encrypted disks:



      1. crypt containing the root partition of raspbian stretch

      2. usb-crypt is an external usb disk. LVM is used on that disk.

      Both disks are protected using the same passphrase, but the master key is different according to "cryptsetup luksDump". Neither of the two disks are configured using a key file (only one key slot is used for each LUKS container).



      When the system is booting, it is asking for the passphrase of "crypt", but usb-crypt is automatically mounted without asking for a passphrase. Note: I started with an unencrypted root partition, and with that setup, I was asked for the passphrase of usb-crypt during boot.



      Here is the detailed setup:



      $ sudo dmsetup ls --target crypt
      crypt (254, 0)
      usb-crypt (254, 1)

      $ sudo cat /etc/fstab
      /dev/mmcblk0p1 /boot vfat defaults 0 2
      /dev/mapper/crypt / ext4 defaults,noatime 0 1
      # ...
      UUID=b9fb061f-0877-4d2c-bd3c-9c155b8f88a5 /mountpoint ext4 rw,auto 0 0

      $ sudo cat /etc/crypttab
      # <target name> <source device> <key file> <options>
      crypt /dev/mmcblk0p2 none luks
      usb-crypt UUID=31fb8df7-6148-4408-90a2-93b8ec752fa0 none luks


      While having only to type the passphrase once is convenient, I am surprised seeing this behaviour. I'd have expected to be asked for both passphrases.



      Is this related to using the same passphrase on both disks? Or is the master key of the usb disk automatically saved somewhere in the encrypted root partition of "crypt"? I'd appreciate if someone could explain what's going on here and maybe give some hints to relevant log files, etc.



      Thanks in advance!







      share|improve this question












      On my system, I have two encrypted disks:



      1. crypt containing the root partition of raspbian stretch

      2. usb-crypt is an external usb disk. LVM is used on that disk.

      Both disks are protected using the same passphrase, but the master key is different according to "cryptsetup luksDump". Neither of the two disks are configured using a key file (only one key slot is used for each LUKS container).



      When the system is booting, it is asking for the passphrase of "crypt", but usb-crypt is automatically mounted without asking for a passphrase. Note: I started with an unencrypted root partition, and with that setup, I was asked for the passphrase of usb-crypt during boot.



      Here is the detailed setup:



      $ sudo dmsetup ls --target crypt
      crypt (254, 0)
      usb-crypt (254, 1)

      $ sudo cat /etc/fstab
      /dev/mmcblk0p1 /boot vfat defaults 0 2
      /dev/mapper/crypt / ext4 defaults,noatime 0 1
      # ...
      UUID=b9fb061f-0877-4d2c-bd3c-9c155b8f88a5 /mountpoint ext4 rw,auto 0 0

      $ sudo cat /etc/crypttab
      # <target name> <source device> <key file> <options>
      crypt /dev/mmcblk0p2 none luks
      usb-crypt UUID=31fb8df7-6148-4408-90a2-93b8ec752fa0 none luks


      While having only to type the passphrase once is convenient, I am surprised seeing this behaviour. I'd have expected to be asked for both passphrases.



      Is this related to using the same passphrase on both disks? Or is the master key of the usb disk automatically saved somewhere in the encrypted root partition of "crypt"? I'd appreciate if someone could explain what's going on here and maybe give some hints to relevant log files, etc.



      Thanks in advance!









      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 17 '17 at 20:55









      wiede

      333




      333




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          6
          down vote



          accepted










          Depends on what the init script that asks the password of you is doing with it.



          If it's systemd, it might just be a feature. systemd-ask-password comes with a cache functionality that might be responsible.



          https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html




          --accept-cached

          If passed, accept cached passwords, i.e. passwords previously entered.

          --multiple

          When used in conjunction with --accept-cached accept multiple passwords.
          This will output one password per line.



          In this fashion it would first try the passwords you already entered, and only ask for another passwords if that didn't work.



          The downside of such an idea is that checking a password takes 1 second of CPU time with LUKS, so if you had a lot of LUKS containers, these attempts might slow you down. But most people have only one or two and it's actually not uncommon for them to use the same passphrase.



          I actually couldn't locate the source code specifically responsible for this, so the above is only conjecture and I have no idea if this is a feature you could choose to disable somehow.




          Found what seems to be the responsible code, see it here on Github.



          There's a for loop that starts with tries = 0 and increments tries by one each iteration.



          This loop calls get_password() with bool accept_cached set to true if tries == 0 && !arg_verify. So if there are already passwords cached in the first iteration of the loop, it will just return the cached passwords. If those don't work, next iteration with tries == 1 sets accept_cached to false and only then it will ask you to provide another passphrase to try with.



          The list of passwords is passed on to attach_luks_or_plain(). This will be the previously cached password(s) in the first iteration, and the single new password in all following ones, so it won't re-try previously tried passwords (unless perhaps if you keep typing in the same one).



          As for keeping passwords plaintext in memory, the list of passwords is declared as a _cleanup_strv_free_erase_ char **passwords = NULL; so that at least makes it sounds like cleanup will be taken care of properly at some point.



          Keys are always in memory somewhere, that much can't be helped, crypt needs masterkey to work, as long as the container is open, you can always see it with dmsetup table --showkeys.




          It seems like you normally have arg_tries = 3 three attempts to enter a working passphrase, but if you have multiple containers and the cached passwords didn't work, it will only give you two tries to enter the passphrase, since the cached password attempt already counts as the first try. I have no encrypted systemd machine to test if this is true or I'm just misreading the code somewhere.






          share|improve this answer






















          • Thanks - yes it is systemd. I'm completely failing to check which options are passed to systemd-ask-password though. I suspect that this is done through the binary file /lib/cryptsetup/askpass ... But does it mean that the password is stored in plaintext in memory?
            – wiede
            Nov 18 '17 at 10:29











          • @wiede Yes. I have updated my answer.
            – frostschutz
            Nov 18 '17 at 12:22










          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405345%2fwhy-is-my-luks-partition-mounted-without-asking-for-a-passphrase%23new-answer', 'question_page');

          );

          Post as a guest






























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          6
          down vote



          accepted










          Depends on what the init script that asks the password of you is doing with it.



          If it's systemd, it might just be a feature. systemd-ask-password comes with a cache functionality that might be responsible.



          https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html




          --accept-cached

          If passed, accept cached passwords, i.e. passwords previously entered.

          --multiple

          When used in conjunction with --accept-cached accept multiple passwords.
          This will output one password per line.



          In this fashion it would first try the passwords you already entered, and only ask for another passwords if that didn't work.



          The downside of such an idea is that checking a password takes 1 second of CPU time with LUKS, so if you had a lot of LUKS containers, these attempts might slow you down. But most people have only one or two and it's actually not uncommon for them to use the same passphrase.



          I actually couldn't locate the source code specifically responsible for this, so the above is only conjecture and I have no idea if this is a feature you could choose to disable somehow.




          Found what seems to be the responsible code, see it here on Github.



          There's a for loop that starts with tries = 0 and increments tries by one each iteration.



          This loop calls get_password() with bool accept_cached set to true if tries == 0 && !arg_verify. So if there are already passwords cached in the first iteration of the loop, it will just return the cached passwords. If those don't work, next iteration with tries == 1 sets accept_cached to false and only then it will ask you to provide another passphrase to try with.



          The list of passwords is passed on to attach_luks_or_plain(). This will be the previously cached password(s) in the first iteration, and the single new password in all following ones, so it won't re-try previously tried passwords (unless perhaps if you keep typing in the same one).



          As for keeping passwords plaintext in memory, the list of passwords is declared as a _cleanup_strv_free_erase_ char **passwords = NULL; so that at least makes it sounds like cleanup will be taken care of properly at some point.



          Keys are always in memory somewhere, that much can't be helped, crypt needs masterkey to work, as long as the container is open, you can always see it with dmsetup table --showkeys.




          It seems like you normally have arg_tries = 3 three attempts to enter a working passphrase, but if you have multiple containers and the cached passwords didn't work, it will only give you two tries to enter the passphrase, since the cached password attempt already counts as the first try. I have no encrypted systemd machine to test if this is true or I'm just misreading the code somewhere.






          share|improve this answer






















          • Thanks - yes it is systemd. I'm completely failing to check which options are passed to systemd-ask-password though. I suspect that this is done through the binary file /lib/cryptsetup/askpass ... But does it mean that the password is stored in plaintext in memory?
            – wiede
            Nov 18 '17 at 10:29











          • @wiede Yes. I have updated my answer.
            – frostschutz
            Nov 18 '17 at 12:22














          up vote
          6
          down vote



          accepted










          Depends on what the init script that asks the password of you is doing with it.



          If it's systemd, it might just be a feature. systemd-ask-password comes with a cache functionality that might be responsible.



          https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html




          --accept-cached

          If passed, accept cached passwords, i.e. passwords previously entered.

          --multiple

          When used in conjunction with --accept-cached accept multiple passwords.
          This will output one password per line.



          In this fashion it would first try the passwords you already entered, and only ask for another passwords if that didn't work.



          The downside of such an idea is that checking a password takes 1 second of CPU time with LUKS, so if you had a lot of LUKS containers, these attempts might slow you down. But most people have only one or two and it's actually not uncommon for them to use the same passphrase.



          I actually couldn't locate the source code specifically responsible for this, so the above is only conjecture and I have no idea if this is a feature you could choose to disable somehow.




          Found what seems to be the responsible code, see it here on Github.



          There's a for loop that starts with tries = 0 and increments tries by one each iteration.



          This loop calls get_password() with bool accept_cached set to true if tries == 0 && !arg_verify. So if there are already passwords cached in the first iteration of the loop, it will just return the cached passwords. If those don't work, next iteration with tries == 1 sets accept_cached to false and only then it will ask you to provide another passphrase to try with.



          The list of passwords is passed on to attach_luks_or_plain(). This will be the previously cached password(s) in the first iteration, and the single new password in all following ones, so it won't re-try previously tried passwords (unless perhaps if you keep typing in the same one).



          As for keeping passwords plaintext in memory, the list of passwords is declared as a _cleanup_strv_free_erase_ char **passwords = NULL; so that at least makes it sounds like cleanup will be taken care of properly at some point.



          Keys are always in memory somewhere, that much can't be helped, crypt needs masterkey to work, as long as the container is open, you can always see it with dmsetup table --showkeys.




          It seems like you normally have arg_tries = 3 three attempts to enter a working passphrase, but if you have multiple containers and the cached passwords didn't work, it will only give you two tries to enter the passphrase, since the cached password attempt already counts as the first try. I have no encrypted systemd machine to test if this is true or I'm just misreading the code somewhere.






          share|improve this answer






















          • Thanks - yes it is systemd. I'm completely failing to check which options are passed to systemd-ask-password though. I suspect that this is done through the binary file /lib/cryptsetup/askpass ... But does it mean that the password is stored in plaintext in memory?
            – wiede
            Nov 18 '17 at 10:29











          • @wiede Yes. I have updated my answer.
            – frostschutz
            Nov 18 '17 at 12:22












          up vote
          6
          down vote



          accepted







          up vote
          6
          down vote



          accepted






          Depends on what the init script that asks the password of you is doing with it.



          If it's systemd, it might just be a feature. systemd-ask-password comes with a cache functionality that might be responsible.



          https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html




          --accept-cached

          If passed, accept cached passwords, i.e. passwords previously entered.

          --multiple

          When used in conjunction with --accept-cached accept multiple passwords.
          This will output one password per line.



          In this fashion it would first try the passwords you already entered, and only ask for another passwords if that didn't work.



          The downside of such an idea is that checking a password takes 1 second of CPU time with LUKS, so if you had a lot of LUKS containers, these attempts might slow you down. But most people have only one or two and it's actually not uncommon for them to use the same passphrase.



          I actually couldn't locate the source code specifically responsible for this, so the above is only conjecture and I have no idea if this is a feature you could choose to disable somehow.




          Found what seems to be the responsible code, see it here on Github.



          There's a for loop that starts with tries = 0 and increments tries by one each iteration.



          This loop calls get_password() with bool accept_cached set to true if tries == 0 && !arg_verify. So if there are already passwords cached in the first iteration of the loop, it will just return the cached passwords. If those don't work, next iteration with tries == 1 sets accept_cached to false and only then it will ask you to provide another passphrase to try with.



          The list of passwords is passed on to attach_luks_or_plain(). This will be the previously cached password(s) in the first iteration, and the single new password in all following ones, so it won't re-try previously tried passwords (unless perhaps if you keep typing in the same one).



          As for keeping passwords plaintext in memory, the list of passwords is declared as a _cleanup_strv_free_erase_ char **passwords = NULL; so that at least makes it sounds like cleanup will be taken care of properly at some point.



          Keys are always in memory somewhere, that much can't be helped, crypt needs masterkey to work, as long as the container is open, you can always see it with dmsetup table --showkeys.




          It seems like you normally have arg_tries = 3 three attempts to enter a working passphrase, but if you have multiple containers and the cached passwords didn't work, it will only give you two tries to enter the passphrase, since the cached password attempt already counts as the first try. I have no encrypted systemd machine to test if this is true or I'm just misreading the code somewhere.






          share|improve this answer














          Depends on what the init script that asks the password of you is doing with it.



          If it's systemd, it might just be a feature. systemd-ask-password comes with a cache functionality that might be responsible.



          https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html




          --accept-cached

          If passed, accept cached passwords, i.e. passwords previously entered.

          --multiple

          When used in conjunction with --accept-cached accept multiple passwords.
          This will output one password per line.



          In this fashion it would first try the passwords you already entered, and only ask for another passwords if that didn't work.



          The downside of such an idea is that checking a password takes 1 second of CPU time with LUKS, so if you had a lot of LUKS containers, these attempts might slow you down. But most people have only one or two and it's actually not uncommon for them to use the same passphrase.



          I actually couldn't locate the source code specifically responsible for this, so the above is only conjecture and I have no idea if this is a feature you could choose to disable somehow.




          Found what seems to be the responsible code, see it here on Github.



          There's a for loop that starts with tries = 0 and increments tries by one each iteration.



          This loop calls get_password() with bool accept_cached set to true if tries == 0 && !arg_verify. So if there are already passwords cached in the first iteration of the loop, it will just return the cached passwords. If those don't work, next iteration with tries == 1 sets accept_cached to false and only then it will ask you to provide another passphrase to try with.



          The list of passwords is passed on to attach_luks_or_plain(). This will be the previously cached password(s) in the first iteration, and the single new password in all following ones, so it won't re-try previously tried passwords (unless perhaps if you keep typing in the same one).



          As for keeping passwords plaintext in memory, the list of passwords is declared as a _cleanup_strv_free_erase_ char **passwords = NULL; so that at least makes it sounds like cleanup will be taken care of properly at some point.



          Keys are always in memory somewhere, that much can't be helped, crypt needs masterkey to work, as long as the container is open, you can always see it with dmsetup table --showkeys.




          It seems like you normally have arg_tries = 3 three attempts to enter a working passphrase, but if you have multiple containers and the cached passwords didn't work, it will only give you two tries to enter the passphrase, since the cached password attempt already counts as the first try. I have no encrypted systemd machine to test if this is true or I'm just misreading the code somewhere.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 18 '17 at 12:28

























          answered Nov 17 '17 at 21:21









          frostschutz

          24.6k14774




          24.6k14774











          • Thanks - yes it is systemd. I'm completely failing to check which options are passed to systemd-ask-password though. I suspect that this is done through the binary file /lib/cryptsetup/askpass ... But does it mean that the password is stored in plaintext in memory?
            – wiede
            Nov 18 '17 at 10:29











          • @wiede Yes. I have updated my answer.
            – frostschutz
            Nov 18 '17 at 12:22
















          • Thanks - yes it is systemd. I'm completely failing to check which options are passed to systemd-ask-password though. I suspect that this is done through the binary file /lib/cryptsetup/askpass ... But does it mean that the password is stored in plaintext in memory?
            – wiede
            Nov 18 '17 at 10:29











          • @wiede Yes. I have updated my answer.
            – frostschutz
            Nov 18 '17 at 12:22















          Thanks - yes it is systemd. I'm completely failing to check which options are passed to systemd-ask-password though. I suspect that this is done through the binary file /lib/cryptsetup/askpass ... But does it mean that the password is stored in plaintext in memory?
          – wiede
          Nov 18 '17 at 10:29





          Thanks - yes it is systemd. I'm completely failing to check which options are passed to systemd-ask-password though. I suspect that this is done through the binary file /lib/cryptsetup/askpass ... But does it mean that the password is stored in plaintext in memory?
          – wiede
          Nov 18 '17 at 10:29













          @wiede Yes. I have updated my answer.
          – frostschutz
          Nov 18 '17 at 12:22




          @wiede Yes. I have updated my answer.
          – frostschutz
          Nov 18 '17 at 12:22

















           

          draft saved


          draft discarded















































           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f405345%2fwhy-is-my-luks-partition-mounted-without-asking-for-a-passphrase%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Displaying single band from multi-band raster using QGIS

          How many registers does an x86_64 CPU actually have?