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

31–37 of 37 posts

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

#31

Post by rwmj »

rbanffy wrote: post #28
rwmj wrote: post #10

Earlier quoted context omitted.

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?

I work for Red Hat and this is how VMs are configured by default if you buy RHV, RHOSP, KubeVirt or similar on-prem or public virtualization or cloud products from us. You can turn some of these mitigations off if you want, although I wouldn't personally recommend it - at some time of another there has been a security critical bug which has been mitigated by each one of these changes.

Some of our customers are running untrusted VMs in their public clouds using this configuration. Others will be running on-premises virtualization set ups with VMs from across their companies which can be equally risky.

SELinux is probably the most important mitigation in the list, and while it has a bad reputation that's mostly from people who haven't used it for over a decade. I have SELinux enforcing on every machine I use, and it rarely causes an issue.

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

#32

Post by walrus01 »

rwmj wrote: post #27
theantonym wrote: post #15

Earlier quoted context omitted.

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.c…

most tftpd (note: not ftpd or sftpd) were really not intended to be exposed to the traffic of a public internet connection. They're for stuff like serving an image to a voip phone that is booting on a LAN with tftp parameters to go and get a .xml provisioning file.

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

#33

Post by namibj »

pnutjam wrote: post #23
PyroLagus wrote: post #14

Earlier quoted context omitted.

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

replace dd with shell redirection or cat...

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

#34

Post by StavrosK »

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…

Does this mean I can use this to boot ISOs off my home server? That would be great for installing Ubuntu, for example. Is there a guide on how to do this somewhere?

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

#35

Post by kpcyrd »

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?

>> server spoofing attacks (as in attackers changing the code you boot) > Can you elaborate?

I think this is referring to the server being compromised. This isn't something that can be solved easily because while the bootloader could include signify[1] to verify its downloads, the bootloader itself can't be verified with anything. (disclaimer: I don't know very much about iPXE)

https://www.openbsd.org/papers/bsdcan-signify.html

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

#36

Post by AnthonBerg »

AnthonBerg wrote: post #7
jai_ wrote: post #6

Earlier quoted context omitted.

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

It is unknown. It might be unknowable.

Due to a couple downvotes I want to explain by way of a question: Can it to your knowledge be proven that QEMU is fully secure?

Given that bugs which have been found in it previously have been fixed, can we know from now on that it’s 100% safe?

As far as I know there does not exist a way of rigorously proving that.

fwiw my interest in theoretical computers and formal verification based on this fundamental aspect.

Post reply on HN