search

dnschneid / crouton

Chromium OS Universal Chroot Environment
https://goo.gl/fd3zc?si=1
BSD 3-Clause "New" or "Revised" License
8.57k stars 1.24k forks source link

decryption of newly encrypted chroot reliably fails #3947

Closed TimFH closed 5 years ago

TimFH commented 5 years ago

Please paste the output of the following command here: sudo edit-chroot -all chronos@localhost ~/Downloads $ sudo edit-chroot -all name: trusty encrypted: yes, locked Unmounting /mnt/stateful_partition/crouton/chroots/trusty... name: xenial encrypted: yes, locked Unmounting /mnt/stateful_partition/crouton/chroots/xenial...

Please describe your issue:

Every time I try to encrypt my new chroot and then enter it, it says "Failed to decrypt xenial." as if I typed the passphrase wrong. Doesn't matter if I encrypt it when I create it with crouton or later with edit-chroot. Decryption does still work on old chroots. To make sure I'm not losing my mind, I cut the passphrase down to a single character that I absolutely could not possibly be typing incorrectly, and it still happens. Am I jinxed or is everyone having this problem?

If known, describe the steps to reproduce the issue:

TimFH commented 5 years ago

Postscript: The following tail of /var/log/messages following an attempt to enter the encrypted chroot appear relevant:

2018-11-23T14:39:22.104987-08:00 ERR ecryptfs-unwrap-passphrase[26324]: Failed to detect wrapped passphrase version: Invalid argument 2018-11-23T14:39:22.355093-08:00 ERR ecryptfs-unwrap-passphrase[26329]: Incorrect wrapping key for file [/tmp/tmp.NqxCVTiKmm] 2018-11-23T14:39:57.813827-08:00 ERR ecryptfs-unwrap-passphrase[26363]: Failed to detect wrapped passphrase version: Invalid argument 2018-11-23T14:39:58.054423-08:00 ERR ecryptfs-unwrap-passphrase[26368]: Incorrect wrapping key for file [/tmp/tmp.nHtpdC2pvE] 2018-11-23T14:40:56.193503-08:00 ERR ecryptfs-rewrap-passphrase[26748]: Failed to detect wrapped passphrase version: Invalid argument 2018-11-23T14:41:19.673955-08:00 ERR cras_server[1557]: Unable to find the best channel map 2018-11-23T14:42:45.596298-08:00 ERR cras_server[1557]: message repeated 2 times: [ Unable to find the best channel map] 2018-11-23T14:44:11.763348-08:00 ERR ecryptfs-unwrap-passphrase[27231]: Failed to detect wrapped passphrase version: Invalid argument 2018-11-23T14:44:12.006377-08:00 ERR ecryptfs-unwrap-passphrase[27236]: Incorrect wrapping key for file [/tmp/tmp.68qc0TXdu4]

kanouharu commented 5 years ago

I'm having this problem as well. I've tried on 5 separate occasions to encrypt and decrypt my little chroots . No dice.

merc32 commented 5 years ago

I am having the same issue.

caroleenc commented 5 years ago

I needed a quick workaround to this issue so I just ran it without encryption. I had to remove it and rerun the crouton file.

To remove: sudo delete-chroot xenial Rerunning on touchscreen Chromebook note no "-e" : sudo sh ~/Downloads/crouton -t touch,xfce

It'll ask for a password, linux username, linux password

LynWales commented 5 years ago

I am experiencing exactly the same issue which has only appeared recently. I have tested encryption this morning and my attempt has failed again even with a one word password. I am currently using an un-encrypted root which I am nervous about Any sign of a fix/

pshotton commented 5 years ago

Same for me. I've been using crouton for ages. Decided to start afresh on my Chromebook Pixel - powerwashed it and installed a xenial chroot from scratch. After installing I couldn't enter the chroot - failed to decrypt. Deleted the chroot and reinstalled - exactly the same. Old chroots continue to work fine.

scuba-tech commented 5 years ago

Same exact issue - have a very simple password to test, fresh install, reliably fails every single time. Am currently running without encryption (ahhh!!)

cheerfulcharlie commented 5 years ago

Same exact issue. Every chroot I create on my new Pixel Slate reliably fails if encrypted even when using a simple one word password. The effect is the same regardless of whether I initially encrypt the chroot or encrypt after its initial creation.

Even after Powerwashing my Pixel Slate, updating crouton, encryption reliably fails in the same way that the original poster described.

So, I'm currently using unencrypted chroots, which I naturally feel uncomfortable about.

I tried to find solutions to this problem by searching online but nothing I found seems to help. If I can help by posting any logs or follow-up information just let me know what to share, I will happily share it here. If anyone has any trouble-shooting ideas, I'm all ears.

kapilhp commented 5 years ago
  1. Can one disable encryption with edit-chroot?
  2. Does a separate mount-chroot command work?

Edit: Answer is "No!" in both cases.

Edit2: Not just with xenial but with buster too.

Edit3: Don't have this machine right now but it is an Acer R11 running in the beta channel.

memilanuk commented 5 years ago

Again, same problem here. Dell CB 13, stable, XFCE. Multiple tries with multiple chroots using -r xenial, with progressively shorter/simpler passphrases, both encrypted from start and afterwards.

Edit: just tried it with stretch; same results.

dnschneid commented 5 years ago

Could you all please post your Chrome version/platform from about:version?

Looks like parameters have changed.

pshotton commented 5 years ago

Google Chromebook Pixel 2015 running 72 something (don't have it with me at the moment) Google Pixelbook running 72.0.3623.3

On Sat, 22 Dec 2018 at 07:01, David Schneider notifications@github.com wrote:

Could you all please post your Chrome version/platform from about:version?

Looks like parameters have changed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dnschneid/crouton/issues/3947#issuecomment-449550848, or mute the thread https://github.com/notifications/unsubscribe-auth/AE2E8dk73AVqr9xStUYf7P-aHllDTloHks5u7djBgaJpZM4Yw-4W .

cheerfulcharlie commented 5 years ago

In my case, I am running Chrome Version 71.0.3578.57 (Official Build) (64-bit) on a new Pixel Slate. A listing of my current non-encrypted two chroots are as follows:

name: trusty encrypted: no Entering /mnt/stateful_partition/crouton/chroots/trusty... crouton: version 1-20181001133934~master:38012fdf release: trusty architecture: amd64 xmethod: xiwi targets: xfce-desktop,extension,touch,keyboard,xiwi host: version 11151.33.0 (Official Build) stable-channel nocturne kernel: Linux localhost 4.4.159-15338-g1c38ea17cf5d #1 SMP PREEMPT Wed Nov 14 23:43:43 PST 2018 x86_64 x86_64 x86_64 GNU/Linux freon: yes Unmounting /mnt/stateful_partition/crouton/chroots/trusty...

name: xenial2 encrypted: no Entering /mnt/stateful_partition/crouton/chroots/xenial2... crouton: version 1-20181001133934~master:38012fdf release: xenial architecture: amd64 xmethod: xiwi targets: xfce,extension,touch,keyboard,xiwi host: version 11151.33.0 (Official Build) stable-channel nocturne kernel: Linux localhost 4.4.159-15338-g1c38ea17cf5d #1 SMP PREEMPT Wed Nov 14 23:43:43 PST 2018 x86_64 x86_64 x86_64 GNU/Linux freon: yes Unmounting /mnt/stateful_partition/crouton/chroots/xenial2...

Please note that if I try to encrypt either chroot after the fact, I will be unable to decrypt them and then I will have to restore an unencrypted chroot from backup.

I would be happy to send/post any other logs or outputs -- just let me know what you want to see. Many thanks!

memilanuk commented 5 years ago

Dell Chromebook 13 (7310), Version 71.0.3578.94 (Official Build) (64-bit)

name: foo encrypted: no Entering /mnt/stateful_partition/crouton/chroots/foo... crouton: version 1-20181001133934~master:38012fdf release: xenial architecture: amd64 xmethod: xiwi targets: xfce,xiwi,keyboard,cli-extra,chrome host: version 11151.59.0 (Official Build) stable-channel lulu kernel: Linux localhost 3.14.0 #1 SMP PREEMPT Tue Dec 11 00:08:44 PST 2018 x86_64 x86_64 x86_64 GNU/Linux freon: yes

kapilhp commented 5 years ago

On this platform it works! No problems.

Asus Flip C100PA, Version 70.0.3538.110 (Official Build) (32-bit)
Platform | 11021.81.0 (Official Build) stable-channel
crouton: version 1-20181001133934~master:38012fdf
release: buster
architecture: armhf
targets: core
host: version 11021.81.0 (Official Build) stable-channel veyron_minnie 
kernel: Linux localhost 3.14.0 #1 SMP PREEMPT Thu Nov 15 22:39:53 PST 2018 armv7l GNU/Linux
freon: yes
LynWales commented 5 years ago

Attached are screenshots of the version number and detailed build information. Note that updates have been installed since the encryption issue but that I am still unable to encrypt. Lyn Williams(Mr)

On Sat, 22 Dec 2018 at 07:01, David Schneider notifications@github.com wrote:

Could you all please post your Chrome version/platform from about:version?

Looks like parameters have changed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dnschneid/crouton/issues/3947#issuecomment-449550848, or mute the thread https://github.com/notifications/unsubscribe-auth/AjW9nZ06WJVHShF700HycBDwxC5eHYfWks5u7djBgaJpZM4Yw-4W .

kanouharu commented 5 years ago

Google Chrome 71.0.3578.94 (Official Build) beta (64-bit) Revision 6da2ba233559398092dabd8dc7bc8e78cd758307-refs/branch-heads/3578@{#890} Platform 11151.59.0 (Official Build) beta-channel quawks Firmware Version Google_Quawks.5216.204.61 JavaScript V8 7.1.302.31 Flash 32.0.0.101 /opt/google/chrome/pepper/libpepflashplayer.so User Agent Mozilla/5.0 (X11; CrOS x86_64 11151.59.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.94 Safari/537.36 Command Line /opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=32.0.0.101 --ui-prioritize-in-gpu-process --use-gl=egl --enable-native-gpu-memory-buffers --gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --use-cras --enable-wayland-server --user-data-dir=/home/chronos --system-developer-mode --login-profile=user --has-chromeos-keyboard --guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg --guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg --child-wallpaper-large=/usr/share/chromeos-assets/wallpaper/child_large.jpg --child-wallpaper-small=/usr/share/chromeos-assets/wallpaper/child_small.jpg --default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/oem_large.jpg --default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/oem_small.jpg --default-wallpaper-is-oem --enable-consumer-kiosk --enterprise-enrollment-initial-modulus=15 --enterprise-enrollment-modulus-limit=19 --login-manager --first-exec-after-boot --vmodule=nss_cert_database_chromeos=1,*/assistant/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,*night_light*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2 Executable Path /opt/google/chrome/chrome Profile Path /home/chronos/u-92158f09fcba026aeabe2332e2e970f091bf1a5f Variations 411b6d4e-f23d1dea b7d3b6c2-3f4a17df d01ab0d3-2e200496 1a0d11d4-2f9febdf 2b6ab552-ca7d8d80 66df3e9d-f2718d9f b7e2524c-57c64350 411c711e-f23d1dea 6c18ba9d-3f4a17df cc20827f-ca7d8d80 38eb801c-3f4a17df 3e38f260-f8f5001 7c1bc906-8122a015 9def365c-f23d1dea 47e5d3db-3d47f4f4 ae3a5770-f23d1dea 125b7f68-898170a5 d442dfb7-ca7d8d80 71ed337-5b96f4bb a582a1b8-ad75ce17 2a565533-ee63ae02 8ee5ed19-ca7d8d80 74658432-ca7d8d80 98be3390-d93a0620 249dd49a-3f4a17df 116c6887-107b6805 aa011017-3f4a17df 345b5b61-3f4a17df edbcf7c5-ddf1844d b67f0598-5419e7bd 5485fc4d-3f4a17df 93731dca-3d47f4f4 87a01a8d-ca7d8d80 41f007f9-ca7d8d80 9b4c4257-6ad6e56e 4ae380f4-3f4a17df 9e5c75f1-e10fa620 ed40b571-ae9eb0f3 6872f671-991e1e1 2594bdf4-3e4b89c4 7f2c498f-13b68faf 2b86fd96-3f4a17df 2ca9c26b-3f4a17df d1cd70a5-f23d1dea 95876445-2b71ffe4 3f2db1c3-f23d1dea fc369826-3f4a17df b363a81f-ba937583 67246da1-3f4a17df cc54eb06-720b026c 58a025e3-36e97b2c d4d220f9-1c10ba89 4932440-d21eb72d 5586049f-3f4a17df 51b9b54d-f23d1dea 7345ea6-a50b0f4 4bc337ce-3f4a17df 553edbc3-3f4a17df 494d8760-52325d43 3ac60855-486e2a9c f296190c-a0af34c0 4442aae2-6e3b1976 ed1d377-e1cc0f14 75f0f0a0-d7f6b13c e2b18481-6bdfffe7 e7e71889-e1cc0f14 f9e5da91-508355f5 85963571-5419e7bd a4f1de9f-f23d1dea 82ebe475-3f4a17df cc73f8a1-ca02b375 b4e8892d-f23d1dea 8834fcca-7875cca2 6204e469-94a80f74 81c6897f-e872b86f ea0f933d-29e3c6de

kaicio commented 5 years ago

Same here.

Google Chrome 71.0.3578.94 (Build ufficiale) (a 64 bit)
Revisione 6da2ba233559398092dabd8dc7bc8e78cd758307-refs/branch-heads/3578@{#890}
Piattaforma 11151.59.0 (Official Build) stable-channel peppy
Versione firmware Google_Peppy.4389.117.0

chronos@localhost / $ sudo edit-chroot -all Password: name: bionic encrypted: yes, locked

but the same occurs with kali-rolling

JoeBachofen commented 5 years ago

Same problem; running w/o encryption Chrome OS 72.0.3626.30 (Official Build) dev (64 bit) Samsung Chrome 500C

memilanuk commented 5 years ago

Same problem; running w/o encryption

I'm confused... how can you have the same problem - Failure to decrypt if you're running without encryption?

JoeBachofen commented 5 years ago

Sorry, I should have said "Same problem, so I'm running without encryption as a workaround."

ybazlov commented 5 years ago

Same problem: created a brand new encrypted chroot, cannot use it as it fails to decrypt despite the correct passphrase.

Google Chrome | 71.0.3578.94 (Official Build) (64-bit) Revision | 6da2ba233559398092dabd8dc7bc8e78cd758307-refs/branch-heads/3578@{#890} Platform | 11151.59.0 (Official Build) stable-channel cave Firmware Version | Google_Cave.7820.384.0

justinfrankel commented 5 years ago

I've (finally, ugh) figured this out -- in newer ChromeOS versions, ecryptfs-wrap-passphrase etc produces 90 byte keys rather than 80 byte keys. To temporarily workaround (ideally the script should analyze the .ecryptfs file to figure out what sizes are needed?) you can edit /usr/local/bin/mount-chroot:

            # Extract wrapped keys from keyfile
            tail -c 160 "$KEYFILE" | head -c 80 > "$wrappedkey"
            tail -c 80 "$KEYFILE" > "$wrappedfnek"

Change 160 to 180, and both instances of 80 to 90, and that fixes. I'll leave it to the maintainer to add autodetection logic ;)

Edit: side note, looks like ecryptfs now supports a v2 wrapping (the extra 10 bytes are a header of ':' and 2, then an 8 byte wrapping salt).

Edit again: have developed a fix and added a pull request.

tokkibear commented 5 years ago

Hello, I'm also having issues with this as well. Whenever I type in "sudo startcfce4" in, it'll ask for my password and then take it but when it asks to "enter encryption passphrase for xenial", I enter it correctly and then it'll say "failed to decrypt xenial."

I tried finding a solution but I wasn't able to find one ....

I'm not sure what I'm suppose to put down for my specs but here it is. This is the model of my laptop is ASUS Chromebook C302 and the OS is Version 71.0.3578.94 (Official Build) (64-bit)

If there's an alternative way to do it, please let me know!

binMonkey commented 5 years ago

Same problem here. I'm new to a lot of this. Should I check back here for an updated crouton file?

justinfrankel commented 5 years ago

There's a temporary workaround fix in my above post -- hopefully this will get into the main Crouton branch soon (any ETA on that @dnschneid?).

dnschneid commented 5 years ago

The crouton testing infrastructure is currently down due to building migration, so I can't test the fix across multiple channels, devices, architectures, distributions, etc. I really don't want to run the risk of breaking access to long-lived chroots, so this won't get merged until the test infrastructure is back. ETA on that is early next week.

tokkibear commented 5 years ago

@justinfrankel I did try using the workaround but it wasn't going through ... Perhaps I typed it incorrectly .... @dnschneid But thank you guys for providing us the code! I appreciate it

lomax commented 5 years ago

@justinfrankel I did try using the workaround but it wasn't going through ... Perhaps I typed it incorrectly ....

This doesn't work for me eigther, however when i started with unencrypted chroot and than converted it to the encrypted chroot and checked .ecryptfs size to be 181 bytes and than changed 160 -> 180 and 80 -> 90 twice in mount-chroot script, it successfully mounted my converted chroot.

binMonkey commented 5 years ago

I didn't know much about crouton, but I read a little and called on rusty vim skills and justinfrankel's 160 -> 180, 80 -> 90 solution worked for me.

When this fix goes through into a new crouton file, I'll just have to update my existing chroot, right?

Thanks a lot guys.

Lstepppes commented 5 years ago

Hey i'm still struggling with this problem i don't know how to use the justinfranklin's code

binMonkey commented 5 years ago

Lstepppes, it's mostly easy to do.

Once you're in the shell, type " sudo vi /usr/local/bin/mount-chroot". This will open up the file you need to edit.

The code you have to edit is about 3/4 of the way down, if I remember correctly.

This is the sort of difficult part. You're going to edit using the vi editor. Google around for a quick read on it. Use the arrow key to scroll down to the code you need to edit. When you get to the 6 in 160, type x. STOP AND PAY ATTENTION HERE! Now type i ( for insert ) and enter the 8 to make 180. Now hit ESC and go on to the next bit you need to change. Press x, press i, and make your changes. Once you've made all the changes, hit ESC again, a colon will appear at the bottom of the screen, type wq, and hit enter.

binMonkey commented 5 years ago

Ok. I just updated my ChromeOs 17/01/19 at 2315 UTC, Version 71.0.3578.127 (Official Build) (64-bit) and went to update my crouton. I got the failed to decrypt message, I can still run the chroot as normal, but I can't update.

In /usr/local/bin/mount-chroot 160 is still there, but the 80s have been replaced with 90s.

Disregard all the above. The Chrome Os update had nothing to do with it. Apparently the fix allows you to run a chroot, but not to update one. Is anyone else having trouble updating?

lomax commented 5 years ago

Disregard all the above. The Chrome Os update had nothing to do with it. Apparently the fix allows you to run a chroot, but not to update one. Is anyone else having trouble updating?

As a workaround I manually enter-chroot to mount it and than run the update on already mounted chroot.

P.S. as I can see PR were merged, so it should work anyway.

DennisLfromGA commented 5 years ago

PR #3978 has been merged into the master, thanks @justinfrankel

Closing. Please update your chroot and try again, re-open if this issue is still a concern.

binMonkey commented 5 years ago

Ok. I'm sorry to be a pain. I deleted my chroot, downloaded the latest crouton, installed it, and updated the mount-chroot file. It still fails to decrypt.

I've enter[ed]-chroot and tried to update but get this message: crouton can only be installed in the Chromium OS dev mode shell. edit-chroot offers no option to update.

Can someone please give me some direction here, please?

justinfrankel commented 5 years ago

Edit: ah, to update the scripts you can use "sudo sh ~/Downloads/crouton -b".

But: @dnschneid it looks like the releases branch hasn't been updated with the fix?

DennisLfromGA commented 5 years ago

@binMonkey,

I deleted my chroot, downloaded the latest crouton, installed it, and updated the mount-chroot file. It still fails to decrypt.

Editing the mount-chroot script is not needed any longer since the fix has already been merged.

@justinfrankel & @binMonkey

Edit: ah, to update the scripts you can use "sudo sh ~/Downloads/crouton -b".

To update your crouton chroot use the '-u' not the '-b' option, like:

@justinfrankel,

But: @dnschneid it looks like the releases branch hasn't been updated with the fix?

Maybe it was a timing or cache issue but the master file is now showing the changes:

https://github.com/dnschneid/crouton/blob/master/host-bin/mount-chroot#L239

Hope this helps, -DennisLfromGA

justinfrankel commented 5 years ago

Maybe it was a timing or cache issue but the master file is now showing the changes:

It is on master, but the problem is that the releases branch needs to be updated with the changes (since the script pulls a blob from releases/crouton).

justinfrankel commented 5 years ago

To update your crouton chroot use the '-u' not the '-b' option, like:

Yes, but before you can update your encrypted chroot you need to update the scripts that live in /usr/local/bin, and to do this you use -b (but this is moot until the release branch gets updated correctly, CC @dnschneid )

DennisLfromGA commented 5 years ago

@justinfrankel,

  1. You are correct, it looks like the release branch does need an update.
  2. I'm pretty sure the hostbin files get restored with an update but it wouldn't hurt to first apply the '-b' option.

-DennisLfromGA

binMonkey commented 5 years ago

Just because I'm new to github and to make sure I'm not an idiot, the release branch is the crouton file we download here : https://github.com/dnschneid/crouton, right?

And does anyone know where I can place a .vimrc so that set number is permanent when I edit /usr/loca/bin/mount-chroot? I have one in my /home/ directory, but it doesn't scope out to /usr/ocal.

DennisLfromGA commented 5 years ago

@binMonkey,

Just because I'm new to github and to make sure I'm not an idiot, the release branch is the crouton file we download here : https://github.com/dnschneid/crouton, right?

That link is to the landing page for the crouton project. The link you need for the crouton installer is:

But, as @justinfrankel mentioned above the release branch needs to be updated before the fix is in place. I think it would be best to wait for the devs to update crouton rather than edit the script.

Meanwhile you can install a new crouton chroot without encryption and then later, when the fix is in place, just update your chroot and add encryption at the same time using:

And does anyone know where I can place a .vimrc so that set number is permanent when I edit /usr/loca/bin/mount-chroot? I have one in my /home/ directory, but it doesn't scope out to /usr/ocal.

The .vimrc file should be in your home directory: ~/.vimrc and the $MYVIMRC environment variable should point to it. See this page for more detail examples:

Hope this helps, -DennisLfromGA

dnschneid commented 5 years ago

ugh, I suck. OK, pushed a new release.

ybazlov commented 5 years ago

Works great. Can now update the chroot in a "canonical" way. Thanks!

binMonkey commented 5 years ago

dnschneid, you are awesome! Thank you.

binMonkey commented 5 years ago

@DennisLfromGA , my vim is set up correctly, but it doesn't process 'set number' when I sudo.

'vim /usr/loca/bin/mount-chroot' shows numbers.

But 'sudo vim /usr/local/bin/mount-chroot' doesn't. Any ideas?

DennisLfromGA commented 5 years ago

@binMonkey,

I'm not sure what the discrepancy might be but you can turn on line numbering in vim by entering:

Turn line numbering off by entering:

Hope this helps, -DennisLfromGA