I installed OpenSuSe 13.1 using a LVM based encryption layout for partitioning. However, I noticed that by default there is still a 400 MB /boot partition being created, which is not encrypted (and which therefore makes the whole encryption useless for obvious reasons). So my questions are:
Would it be possible to move this /boot partition to a USB stick (so that the system can only be booted using that stick) and to expand the existing LVM layout in order to make the whole disk being encrypted?
If this it not possible: Is there any way to avoid the creation of a non-encrypted boot partition during installation?
That should be possible, though I have not attempted it.
If this it not possible: Is there any way to avoid the creation of a non-encrypted boot partition during installation?
I haven’t tried that, either. But I think you could do that if you went to expert mode in the partitioning. Whether your system would be bootable, is a different issue. You would possibly need to tell the installer to not install any boot loader, and then add that later.
Supposedly, there’s a way of defining “GRUB_ENABLE_CRYPTODISK” in “/etc/default/grub” so that grub will then open the encrypted LVM to get its boot information. I don’t think opensuse fully supports this at the moment, but you might be able to set it up manually. And you might then be prompted twice for the encryption (once for grub2 and once for the kernel).
Putting “/boot” on a USB is probably the easier way to go.
I do not know very much about the subject, but when you want to copy a partition to another place you should not copy the directory it (might be) mounted on (/boot), but the partition itself: (/dev/sdNX.). And I am not sure what the destination must be. When you use the device (/dev/sdM) there will be no partition table on the USB device, but that may be what you need. It could also be that you need a partition on the device, then you have to create that partition first with the correct size (same as the original boot partition).
No, that would not work, because “/boot” is a directory within a file system while the device is a device.
You should be able to partition the USB device. Use just one partition if you want to use the entire device. Then format the partition. I suggest “ext2”. Then copy “/boot” to the new file system (recursively).
Next, mount the new file system as “/boot” (on top of your current “/boot” is okay. Modify “/etc/fstab” so that it will mount this in future. Then reinstall grub2 – perhaps using “/usr/sbin/grub2-install” or using Yast Boot Loader.
If you put “noauto” in the fstab entry, then the USB should not actually be mounted on boot, so you can remove it after booting. You would need to manually mount it when installing kernel updates.
You do understand that an unencrypted boot is no problem in that it only contains the kernel and start up files. The main system and data is still encrypted and you have to supply the password to unlock it. You must have an unencrypted starting place since the BIOS does not know how to read an encrypted partition to start grub then the kernel and so forth.
Placing boot on USB can work but USBs may be seen by the system as different device and my not start as a consistent /dev/sdX This can cause problems in mounting.
I assume this is a MBR formatted drive rather the GPT EFI Because in EFI the EFI boot partition is also not encrypted
Note that if a bad guy has your password and physical access it makes no difference if there is no boot on the drive they can still mount the partition and use the password to decrypt Not having the USB would not slow them down at all
That’s exactly the point. It’s obvious that if someone knows the password for your encrypted drive that he can also access it then. But it’s also obvious that he first needs to acquire that password for being able to do so.
The method adviced by nrickert sounds very good to me, thanks a lot for that. I will try it out today.
If this method works, I think it would be not a bad idea to create backups of the /boot USB stick according to my experiences with the reliability of USB sticks.
> Supposedly, there’s a way of defining “GRUB_ENABLE_CRYPTODISK” in
> “/etc/default/grub” so that grub will then open the encrypted LVM to get
> its boot information. I don’t think opensuse fully supports this at the
> moment, but you might be able to set it up manually. And you might then
> be prompted twice for the encryption (once for grub2 and once for the
> kernel).
Notice that grub itself is not encrypted, it resides outside of any
partition, and it contains the decryption code >:-)
(not the key)
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-10-23 21:26, ger kor linuxdev wrote:
>
> Hello,
>
> I installed OpenSuSe 13.1 using a LVM based encryption layout for
> partitioning. However, I noticed that by default there is still a 400 MB
> /boot partition being created, which is not encrypted (and which
> therefore makes the whole encryption useless for obvious reasons). So my
> questions are:
No, not at all obvious.
There is no decryption key in there, there is no data. There is just
some code needed to boot the machine, code that anyone can obtain from
outside.
It is considered safe.
In fact, any encryption method you use, even in Windows, does the same.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-10-24 01:26, nrickert wrote:
>
> gogalthorp;2670921 Wrote:
>> You do understand that an unencrypted boot is no problem in that it only
>> contains the kernel and start up files.
>
> That depends on what kind of risk you are worried about. If somebody
> has access to “/boot” they can potentially install malware inside the
> “initrd”.
Yes. And this is the very thing that UEFI secure boot protects against.
Not an evil design of Microsoft, but a good thing!
Of course, a bad party with physical access could still change it, and
implant a key on the BIOS table, so that it booted fine >:-)
So you also need to password protect the BIOS.
But then they may reset the jumper.
But then, possibly, the anti-tamper FLAG in the case would trigger.
But then…
Better hire an armed guard.
But then he could be bribed.
But then…
LOL. Good night!
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
[QUOTE=robin_listas;2671272]
> That depends on what kind of risk you are worried about. If somebody
> has access to “/boot” they can potentially install malware inside the
> “initrd”.
Yes. And this is the very thing that UEFI secure boot protects against.
Not really.
With physical access to the machine, they can boot with the live rescue CD which will pass the secure-boot checks. From there, they could tamper with the “initrd” in “/boot” (perhaps plant a key-logger to record the key as it is typed in).
On 2014-10-26 05:56, ger kor linuxdev wrote:
>
> nrickert;2671273 Wrote:
>>> robin_listas;2671272 Wrote:
>>>
>>>> That depends on what kind of risk you are worried about. If somebody
>>>> has access to “/boot” they can potentially install malware inside the
>>>> “initrd”.
>>>
>>> Yes. And this is the very thing that UEFI secure boot protects against.
>>>
>> Not really.
>>
>> With physical access to the machine, they can boot with the live rescue
>> CD which will pass the secure-boot checks.
You can disable that in UEFI. Actually, you MUST do disable booting from
alternate device, specially an external one.
Or at least, the external device booter must be signed, and for the
signature to be valid, it must come untampered from openSUSE. You can
build your own, but the signing key must be one that the local uefi
recognizes because it has been locally added, or is in the Microsoft
controlled loop. That is at least what I understand.
However, initrd is out, because it is always built locally.
So, you do have to disable external booting.
>> From there, they could
>> tamper with the “initrd” in “/boot” (perhaps plant a key-logger to
>> record the key as it is typed in).> >
>>
> Exactly.
>
> Of course the things robin_listas wrote are true: It’s all about risk
> REDUCTION.
It wasn’t me
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
