Snappy + root encryption

[Victor Palau]

Hi Xavier,

On Thu, Aug 25, 2016 at 5:10 PM, Xavier Pegenaute M2M <
xavier.pegenaute at nexiona.com> wrote:

> 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.
>
But surely if someone takes the hardware, they just need to boot it and it
will decrypt itself. So unless you are storing the decryption key outside
the device I am not sure how this will provide you additional security. no?

>
> 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
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/snapcraft
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160825/57abe38a/attachment.html>