Hello all,
I'm trying to get Puppy installed on a 8GB USB flash drive with full-disk encryption.
However, I see no way to split the /boot from / partitions in the installer.
Note that it's critical to me that both the OS and Data areas are secured under encryption, leaving only the /boot exposed (which I can MD5 or similar once boot starts to see if it was tampered with).
The ideal layout for me would be:
sba1 - 1GB - EXT4 or similar
sba2 - 7GB - LUKS
Any help on achieving the above would be greatly appreciated.
My current attempts revolve around booting XenialPup64 v7.5 from CD-ROM but with no luck.
Many thanks,
NeoGeo
How to install Puppy on USB Flash drive w/ full-disk LUKS?
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
One question.
Why is it so important to you to have full-disk encryption on a Puppy? (An OS which, by its very nature, is more secure than most other Linux distros.....due to the read-only file-system copied to ramdisk, and the ease with which the configurations can be replaced.)
And you want to check the /boot folder, too.....every time before you boot into it?
If security is that important to you, I honestly think you'd be better off using something like Qubes, or Tails.....distros which were built around the concept of security & privacy from the ground up. Puppy has a habit of being somewhat 'stubborn' under heavy, full-disk encryption......and is no longer the fast, nimble, lightweight OS it's meant to be.
Mike.
Why is it so important to you to have full-disk encryption on a Puppy? (An OS which, by its very nature, is more secure than most other Linux distros.....due to the read-only file-system copied to ramdisk, and the ease with which the configurations can be replaced.)
And you want to check the /boot folder, too.....every time before you boot into it?
If security is that important to you, I honestly think you'd be better off using something like Qubes, or Tails.....distros which were built around the concept of security & privacy from the ground up. Puppy has a habit of being somewhat 'stubborn' under heavy, full-disk encryption......and is no longer the fast, nimble, lightweight OS it's meant to be.
Mike.
Hello Mike,
Many thanks for taking interest in my question!
So, my specific use case is a custom, off-line bitcoin wallet... Which I know puppy is not designed for specifically.
Another criteria I have though is small size, so this really works for me...
General encryption (of a second partition) would work for me, but it leaves open the potential for a keylogger or other attack vector being introduced onto the key's OS since it is entirely open for anyone to execute. In the case of puppy this would take the form of replacement of the SFS or modification of SaveFile/PET I suspect...
It's a really unlikely scenario. With that said, I'm first aiming for a perfect implementation of this idea, then I'll pare back if need-be...
Re: Tails - this is a great idea, and one I already had and attempted but I ran into a major issue: One of the things I need on the distro is a local web-server as many of the Wallet tools I plan on using are written using HTML and JS, which when executed in the browser via file:// do not function the same as they do when going through a server (I think this has to do with CORS or other browser safety rules, not entirely sure). I was able to setup apache2 on tails but getting it to let me access localhost wasn't happening, and making that all happen persistently on startup was also not happening for me.
Additionally, tails also suffers from the same image-replacement attach schema I described above, but could be mitigated by running a MD5 or similar hash against the raw primary partition... and then alerting the user to the delta and giving them the option to update the stored hash (in the event they are the person who made the update) or shutdown screaming...
I just like addressing the threat model at this level I guess - sure it sounds paranoid... and is
But that's my goal
Thanks again for your interest and question - If you have any other suggestions I really do appreciate them.
Be well,
Ng
Many thanks for taking interest in my question!
So, my specific use case is a custom, off-line bitcoin wallet... Which I know puppy is not designed for specifically.
Another criteria I have though is small size, so this really works for me...
General encryption (of a second partition) would work for me, but it leaves open the potential for a keylogger or other attack vector being introduced onto the key's OS since it is entirely open for anyone to execute. In the case of puppy this would take the form of replacement of the SFS or modification of SaveFile/PET I suspect...
It's a really unlikely scenario. With that said, I'm first aiming for a perfect implementation of this idea, then I'll pare back if need-be...
Re: Tails - this is a great idea, and one I already had and attempted but I ran into a major issue: One of the things I need on the distro is a local web-server as many of the Wallet tools I plan on using are written using HTML and JS, which when executed in the browser via file:// do not function the same as they do when going through a server (I think this has to do with CORS or other browser safety rules, not entirely sure). I was able to setup apache2 on tails but getting it to let me access localhost wasn't happening, and making that all happen persistently on startup was also not happening for me.
Additionally, tails also suffers from the same image-replacement attach schema I described above, but could be mitigated by running a MD5 or similar hash against the raw primary partition... and then alerting the user to the delta and giving them the option to update the stored hash (in the event they are the person who made the update) or shutdown screaming...
I just like addressing the threat model at this level I guess - sure it sounds paranoid... and is
But that's my goal Thanks again for your interest and question - If you have any other suggestions I really do appreciate them.
Be well,
Ng