fundamentals..

[J.Wit...@mindef.nl]

Hi again,

 

Perhaps I’m slightly confused with changed naming conventions.

With kiwi-OG and SuSE-studio I could make (with image=”OEM”)  a BLOB (mostly a file with the “*.iso” extension),

Write it to a medium, and use that safely.

 

Looking at configurations I get the impressions that:

a)    Detachable bootable image is intended to be installed on the internal storage of a computer.

b)    Detachable bootable image can completely run independent, never touches internal storage of  computer,
System root remains on the detachable device.

c)    Detachable bootable image, boots, but runs as initrd,
System root is transferred to internal memory (and boot device can be removed)

 

With several variants, such as lvm, overlayfs, squashfs, luks.

Last night experiments with leap-15.6 and tumbleweed seems to indicate that:

1)   “test-image-disk”, “test-image-ramdisk”  all are touching internal storage.

2)   “test-image-live” has its root transferred to memory

3)   “test-image-live” can have either “Statndard” or “Encrypted” profile, but it seems only the image-size is different.
What part has been encrypted?

4)   “test-image-luks” , with profiles insecure, ReEncryptFullDisk, ReEncryptExtraBootEmpyPass, or ReEncrypyExtraBootWithPass don’t yield an image that can be transferred to an USB-stick.

 

Am I mistaken, or do I miss-interpret the documentation?

My goal is to have a secure image on a usb-stick, that can run independently of a pc-drive

(last month I accidentally wiped a laptop’s drive with a kiwi-image)

 

Kind regards, Hans.

 

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[Marcus Schäfer]

Hi Hans,

> Perhaps I’m slightly confused with changed naming conventions.

Let's fix that

> With kiwi-OG and SuSE-studio I could make (with image=”OEM”) a BLOB
> (mostly a file with the “*.iso” extension),
>
> Write it to a medium, and use that safely.

right, suse studio produced an oem disk image (.raw) and an installer
image (.iso) which basically contained that .raw and a simple "installer"
which dumps it to a target. In kiwi speak this is a <type> definition
that has:

<type image="oem" ... installiso="true" .../>

The attribute "installiso" produces a file with the extension .install.iso
When you boot from such an ISO a deployment process is started which
dumps the actual image to some target. The behavior of this deployment
process can be controlled by settings in the <oemconfig> section of the
image build. As it's possible to configure a completely unattended
deployment process which just deploys on the first disk found I
strongly recommend to double check when you use a pre-built image
that you haven't created yourself. In SUSE Studio we had the graphics
interface shown to the builder and could prevent dangerous settings
or at least warn. This is not neccessarily the case with the integration
test images we provide for testing and to get started.

> Last night experiments with leap-15.6 and tumbleweed seems to indicate
> that:
>
> 1) “test-image-disk”, “test-image-ramdisk” all are touching internal
> storage.

test-image-disk exists to test several
image disk layouts and the installation media (if built) would install
to a local storage disk (unattended). test-image-ramdisk exists to test
a system fully deployed into a ramdisk.

> 2) “test-image-live” has its root transferred to memory

test-image-live is a live system. The layout of a live system consists
out of two parts:

- A compressed read-only rootfs, either squashfs or erofs
- An overlay based boot process which overlayfs mounts that read-only
rootfs with either a tmpfs or some persistent storage device.

It does not touch your host unless you explicitly specify an
overlay device via the kernel cmdline

> 3) “test-image-live” can have either “Statndard” or “Encrypted”
> profile, but it seems only the image-size is different.
> What part has been encrypted?

The image size is different because encrypted content cannot really
be compressed as it's random data. The Encrypted profile encrypts
the read-only rootfs. If you pass "rd.live.encrypt" as kernel parameter
also the overlay gets encrypted

It does not touch your host unless you explicitly specify an
overlay device via the kernel cmdline

> 4) “test-image-luks” , with profiles insecure, ReEncryptFullDisk,
> ReEncryptExtraBootEmpyPass, or ReEncrypyExtraBootWithPass don’t yield
> an image that can be transferred to an USB-stick.

test-image-luks is an encrypted disk image, it does not build an
installer iso. You said it cannot be transferred to a stick ? I'm wondering
about that because I just tried:

dd if=kiwi-test-image-luks.x86_64-1.15.1-ReEncryptFullDisk-Build240.4.raw of=/dev/mystick

And boot from stick worked in QEMU

kvm -bios /usr/share/qemu/ovmf-x86_64.bin -hda /dev/mystick

And also on real hardware.

Please note this image only boots in EFI mode. Therefore if you tested that
on a real system, this system must support EFI boot from USB

Please also note, it was pretty slow :)

It does not touch your host as you have to self-deploy it to some device

> My goal is to have a secure image on a usb-stick, that can run
> independently of a pc-drive

From my perspective your best choice is with test-image-live
in encrypted mode and optional overlay data encryption. Be aware
that you have to keep the image description safe and secure because
of the luks passphrase listed in the image description and no way
to re-encrypt on a read-only media. Second best choice is with
test-image-luks.

> (last month I accidentally wiped a laptop’s drive with a kiwi-image)

I'm sorry to hear that. Please take into account that all our
integration test images, all images starting with test-xxx, are also
used for automated end-to-end testing. That's why their configuration
never asks you something before they act. I believe that was the
reason why you accidentally wiped a disk with important data on it.
I'm really sorry and hope you could restore all important data ?

Please do not just out of the box use a .install.iso file on a machine
with important data.

Hope this helps

Regards,
Marcus
--
Public Key available via: https://keybase.io/marcus_schaefer/key.asc
keybase search marcus_schaefer

[J.Wit...@mindef.nl]

Thanks for the feedback!
Will investigate further.

--
You received this message because you are subscribed to the Google Groups "kiwi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kiwi-images...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kiwi-images/aYMmwN-VBqO4Qeav%40asterix.