Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QEMU Advent Calendar: A surprise disk image each day until Christmas

qemu-advent-calendar.org

Post reply on HN
Print view View original

21–30 of 37 posts

Re: QEMU Advent Calendar: A surprise disk image each day until Christmas

#21

Post by LeonM »

candiodari wrote: post #20
ljcn wrote: post #13

Earlier quoted context omitted.

Specifically, for those wondering http://boot.netboot.xyz which in turn does http[s]://boot.netboot.xyz/menu.ipxe

I don't understand the complaints about this. What does https buy you in this case ? Security against your client-server communications' contents being observed by third parties. So here https ... gives ... confidentiality ... to ... public ... images. Well that's useful ! It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ..…

> What does https buy you in this case ?

It ensures the response from the webserver really is from netboot.xyz, and not from any mitm server.

> It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ...

Can you elaborate? How would you spoof the server response without having a valid certificate key for the netboot.xyz domain?

Re: QEMU Advent Calendar: A surprise disk image each day until Christmas

#22

Post by bubblethink »

theantonym wrote: post #15
LeonM wrote: post #3

Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time. It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.

Hi, owner of https://netboot.xyz here. netboot.xyz has https support, with http support still being in place for those that don't have https support compiled into iPXE as it's not compiled by default. I'd recommend checking out the site directly if this is something that interests you. All of the source code running the site is on github as well and we're always open to contributions. We also always try to retrieve t…

netboot.xyz is great! My main use case is to boot things off of drac/ilo etc. If you have a remote server hosted in a datacenter and have struggled to use drac's virtual iso feature, boot the netboot iso. Since it's tiny, it works great for booting, and it switches to the primary NIC once the OS is booting. If you try to use your full iso with drac, it will be painfully slow because it goes through several layers of indirection (reverse proxies set up by your provider, the weird drac driver etc.)

Re: QEMU Advent Calendar: A surprise disk image each day until Christmas

#23

Post by pnutjam »

PyroLagus wrote: post #14
xaduha wrote: post #9

Earlier quoted context omitted.

I wish something like that existed for various single-board computers that are getting popular nowadays. Any sort of flexibility would be welcome, writing big images on a SD card gets old very fast. Yes, many things probably won't boot, but I'd rather find out that they don't quickly.

I don't know about other ones, but you can netboot the Raspberry Pi 3: https://www.raspberrypi.org/documentation/hardware/raspberry...

I use an APU, but with any netboot small computer, I find it easier to netboot a simple linux build and dd the image via netcat, vs plugging and unplugging the card.

My notes for pfsense: receiving machine: netcat -l 2222 | gzip -dc | dd of=/dev/sda

sending machine: dd if=pfSense-2.2.4-RELEASE-2g-i386-nanobsd.img.gz |netcat 10.10.10.101 2222

Re: QEMU Advent Calendar: A surprise disk image each day until Christmas

#24

Post by foxhop »

LeonM wrote: post #3

Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time. It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.

I always assumed people who use netboot are running a distribution mirror inside their "data center".

Re: QEMU Advent Calendar: A surprise disk image each day until Christmas

#26

Post by shittyadmin »

candiodari wrote: post #20
ljcn wrote: post #13

Earlier quoted context omitted.

Specifically, for those wondering http://boot.netboot.xyz which in turn does http[s]://boot.netboot.xyz/menu.ipxe

I don't understand the complaints about this. What does https buy you in this case ? Security against your client-server communications' contents being observed by third parties. So here https ... gives ... confidentiality ... to ... public ... images. Well that's useful ! It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ..…

Assuming they're performing proper CA verification it lowers the trust level from your entire connection to just the CAs and netboot.xyz administrators - preventing MITM attacks in the local network where they're most often performed. Perhaps it's not perfect but it seems like a pretty major improvement.

Re: QEMU Advent Calendar: A surprise disk image each day until Christmas

#27

Post by rwmj »

theantonym wrote: post #15
LeonM wrote: post #3

Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time. It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.

Hi, owner of https://netboot.xyz here. netboot.xyz has https support, with http support still being in place for those that don't have https support compiled into iPXE as it's not compiled by default. I'd recommend checking out the site directly if this is something that interests you. All of the source code running the site is on github as well and we're always open to contributions. We also always try to retrieve t…

Do you serve the main images over tftp and is it reliable? We have been building an NBD server with this use case in mind and had on and off discussions with Foreman people about a similar case. In theory NBD should be much more efficient since it will only serve the main image on demand (but if you want you can still use it like tftp by copying /dev/nbd0 to a ram disk at boot). It also supports TLS.

https://github.com/libguestfs/nbdkit

https://github.com/libguestfs/nbdkit/blob/master/plugins/flo...

Re: QEMU Advent Calendar: A surprise disk image each day until Christmas

#28

Post by rbanffy »

rwmj wrote: post #10
jai_ wrote: post #6

Earlier quoted context omitted.

Is there significant risk in booting untrusted OS images within Qemu?

You need to take steps to harden qemu - I wouldn't do it with qemu out of the box using the command line. In RHEL (eg for Red Hat's OpenStack) we do: * Aggressively compile out unused features/devices. * Confine each VM with separate SELinux contexts (sVirt). * Run qemu as a special non-root user. * Use seccomp to confine the system calls. * Pass in pre-opened file descriptors to qemu, so qemu doesn't need to open fi…

This sounds like a lot of fun. What are you doing with those VMs?

Re: QEMU Advent Calendar: A surprise disk image each day until Christmas

#29

Post by gsich »

LeonM wrote: post #21
candiodari wrote: post #20

Earlier quoted context omitted.

I don't understand the complaints about this. What does https buy you in this case ? Security against your client-server communications' contents being observed by third parties. So here https ... gives ... confidentiality ... to ... public ... images. Well that's useful ! It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ..…

> What does https buy you in this case ? It ensures the response from the webserver really is from netboot.xyz, and not from any mitm server. > It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ... Can you elaborate? How would you spoof the server response without having a valid certificate key for the netboot.xyz domain?

For this to work trusted CAs need to be compiled into the iPXE binary. Since those can change you'll need to update that binary from time to time. Or ignore cert warnings, which reduces the security to plain HTTP.

Re: QEMU Advent Calendar: A surprise disk image each day until Christmas

#30

Post by nerpderp82 »

rwmj wrote: post #10
jai_ wrote: post #6

Earlier quoted context omitted.

Is there significant risk in booting untrusted OS images within Qemu?

You need to take steps to harden qemu - I wouldn't do it with qemu out of the box using the command line. In RHEL (eg for Red Hat's OpenStack) we do: * Aggressively compile out unused features/devices. * Confine each VM with separate SELinux contexts (sVirt). * Run qemu as a special non-root user. * Use seccomp to confine the system calls. * Pass in pre-opened file descriptors to qemu, so qemu doesn't need to open fi…

Please make a gist or blog post!
Post reply on HN