Hi Tyler, All,
my use case is something like this:
we develop some software that can be installed in some hardware provided
by the client. One of our clients requires a snappy distribution. To
protect our data we need to encrypt all FSs in the snappy. Even if at
the moment we have some weak points such as the place were we store the
keys. It is not expected to have a human around every time the snappy
boots but time to time it may be possible.
Our goal is to protect the content in case some one takes the hardware
and mount the partitions as an external drive.
To do so I want to encrypt the FSs with LUKS and provide somehow the key
at boot time and decrypt the FSs: system-a/b, writable and swap. During
this process I am facing some problems which I need to solve asap:
- The configured grub on the FS, apparently does not belong to the real
system. When I run update-grub from a fresh installation does not appear
the same menu options than when booted before.
- The "break=premount" parameter does not work
- The kernel and initrd image are located in /boot but the "boot"
partition point to /boot/efi which I guess it will be a problem when de
rootfs is encrypted.
As a solution, I guess it is better to move the kernel + initrd to
/boot/efi. I will need to only update grub and update-initramfs. Am I
missing something?
Best Regards,
Xavi
On 24/08/16 18:30, Tyler Hicks wrote:
On 08/23/2016 06:47 AM, Xavier Pegenaute M2M wrote:
Hi Mark,
actually, our goal is to provide hardware to be delivered on costumer
premises but for this we need an extra layer of security. This is the
reason we are considering the encryption solution.
If it is possible our first and preferred solution is to encrypt as much
as possible starting from rootfs.
I guess I should port the cryptsetup package and dependencies to snap,
but since I saw in your mailing list some references I wanted to be sure
this is not already done or being in process.
As a second step, AFAIK, I should modify the boot process to include
support for partition decryption which again I am not sure this is
already supported on snappy (crossing fingers xD ).
Will your devices have a display and a keyboard? Will a human always be
present during the boot process (after a planned or unplanned reboot) to
enter the password?
If the answer is 'no' to either of those questions, there's more work to
do in order to provide secure storage of the encryption key in a way
that makes it automatically accessible during the boot process.
Let us know what your needs are and we can at least capture the use case
and requirements in a feature request bug so that we can try to support
you when designing the storage encryption solution in the platform
itself. Thanks!
Tyler
--
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
