One method to encrypt /home/phablet
-
Revisiting this a year later, following a fresh install of OTA-12 on a OnePlus One. It still works.
I did have to bind mount /var/cache/apt as per @jezek 's tip here: https://forums.ubports.com/post/20297
I also dispensed with the cd to /tmp when I remembered that nohup is just writing standard output to a file anyway, so there was no reason not to write to /dev/null, obviating the need to write to a filesystem that will survive the lightdm reload:
nohup /etc/init.d/lightdm force-reload > /dev/null
Will test on PinePhone when I get the chance, but unfortunately my BraveHeart device has been gathering dust for a few months. (Too many projects, too little time, even with all this extra quarantine time in my life. )
As always, DON'T do this unless you know what you're doing* and are prepared to accept the risk of a broken system, either now or at the next OTA.
*A good litmus test might be: you understand what all of the commands in this thread are doing and why they were chosen, as that comprehension implies understanding of the potential consequences as well as the limitations.
-
@trainailleur said in One method to encrypt /home/phablet:
Will test on PinePhone when I get the chance, but unfortunately my BraveHeart device has been gathering dust for a few months. (Too many projects, too little time, even with all this extra quarantine time in my life. )
I finally tested this on the PinePhone (dev channel). It works fine, as expected, though instead of using a file as the encrypted block device, I created a new partition on the sdcard I'm using for testing.
-
Have gone further on the PinePhone and copied all of the writable data into a new luks-encrypted partition.
I now have a shell script in my home directory as initially booted that will:
- check to see if cryptsetup is installed and if not kick off an install script
- turn off swap so we don't end up with encryption keys in swap
- unlock the encrypted partition
- cd to /tmp (because not doing so was tripping me up in the next step)
- force umount /userdata using "umount -l"
- remount the encrypted partition on it
- in sequence force umount each userdata-mounted writeable part of the filesystem using "umount -l" then bind mount it back on the new, encrypted userdata (the bind mounts for your system can be found with findmnt)
- turn swap back on using a new swap file in the encrypted partition with the same -1 setting that the original swap had (a larger swap file, in my case)
- force-reload lightdm
Is anything aside from updates writen to permanent storage other than to bind mounts on /userdata? I didn't find anything, but there's always the possibility that I missed something.
All of this adds a couple of minutes to getting the phone ready for use, of course, and there may be things I've not yet discovered which will turn out to be broken.
Given how much is not yet working in the PinePhone, I should probably replicate this on an Android-based UBPorts device like the OnePlus One or the Nexus 5 for further testing. I'm thinking it should probably work with a large container in /userdata, skipping the umount of /userdata and mounting the decrypted block file (and the consequent bind mounts) on a file within /userdata, but this isn't testing I plan to pursue for now, as other tests take priority.
I am not posting my script here because it only applies to how I have set up my PinePhone. There are a few choices I made which would break completely for someone who made different setup choices. Anyone capable of getting this working on their device will need to understand what is meant by each step above so should be able to develop a process that works for them. If anyone who does want to try this and does know what they're doing hits a snag and has a question, I'll try to answer it.
Standard caveat applies: this could break everything on your phone, and UBPorts developers will not support this or help you fix it. Proceed at your own risk.
-
Seems that lightdm doesn't restart with the latest OTA. Any tips ?
-
@ernest said in One method to encrypt /home/phablet:
Seems that lightdm doesn't restart with the latest OTA. Any tips ?
Hmm. I've not been testing lately so hadn't noticed. Will see what I can figure out when I next have some time, but that may be a while. What errors or symptoms occur?
-
@trainailleur
Lomiri cannot restart thus the screen remains black, while ssh access works fine. -
@ernest said in One method to encrypt /home/phablet:
Seems that lightdm doesn't restart with the latest OTA. Any tips ?
Hi, I'm using the following script (tested on OTA-15 and OTA-16 devel):
#!/bin/bash if ! dpkg-query -l cryptsetup | grep ^ii 1>/dev/null; then mount -o remount,rw / apt-get update && \ apt-get -y install cryptsetup sync mount -o remount,ro / fi cryptsetup luksOpen /home/phablet.img phablet e2fsck /dev/mapper/phablet mount /dev/mapper/phablet /home/phablet && \ nohup /etc/init.d/lightdm force-reload </dev/null >/dev/null 2>&1 &
run as root: sudo bash <nameofscript>
-
@c4pp4 x1000 thanks!!!
-
@ernest said in One method to encrypt /home/phablet:
@trainailleur
Lomiri cannot restart thus the screen remains black, while ssh access works fine.I ran into the same problem on my Nexus 5.
The solution is to lock the screen (Power Button) before initiating the force-reload.
For some reason lightdm does not come back when it was shut down while the display was lit. (It took me quite a while and several WTFs to stumble over this. )
Thus my script is as follows:#!/bin/bash cryptsetup luksOpen /home/phablet.img phablet e2fsck /dev/mapper/phablet mount /dev/mapper/phablet /home/phablet && \ echo "Lock the screen now!" echo "Restart in" for ((t=5;t>0;t--)) do echo "$t s" sleep 1 done cd /tmp nohup /etc/init.d/lightdm force-reload </dev/null >/dev/null 2>&1 &
-
-
This post is deleted!