Compile Dom0 with CONFIG_ETHERNET=N or better yet CONFIG_NET=N

[DemiMarie]

Qubes OS version:

R4.0

Affected component(s):

Dom0 kernel

---

Steps to reproduce the behavior:

Check dom0 kernel configuration

Expected behavior:

dom0 is compiled with CONFIG_ETHERNET=N or better yet CONFIG_NET=N, to ensure that it cannot possibly have a network connection.

Actual behavior:

dom0’s kernel is compiled with CONFIG_ETHERNET=Y.

General notes:

There have been bugs (related to HDMI, for instance) which have caused dom0 to get an Ethernet connection. We can most effectively prevent this by not compiling networking support into the kernel.

---

Related issues:

#2743

[rtiangha]

This would be easier to do if you compile separate kernels for dom0 and domUs. Since the Qubes project uses a shared kernel by default, it makes it harder for them to separate them because the system was never designed to do that. But you can get around it by compiling your own kernels and varying the 'rel' attribute so that you can have multiple kernels (Package "kernel" for dom0 and "kernel-qubes-vm" for domUs) installed each compiled with a different kconfig (ex. 4.14.24-50 for dom0, 4.14.25-100 for VMs, etc). It's what I do, but that's an exercise for the reader.

I believe the Xen network backend and frontend drivers need to be enabled in dom0 in order to make the NICs visible in VMs (if that isn't the case, then please correct me!) and that, in turn, requires CONFIG_NET=y because even if you strip away all network drivers, it still needs TCP/IP socket support (i.e. CONFIG_INET) otherwise the kernel won't boot (trust me, I've tried). However, it might be possible to get away with CONFIG_ETHERNET=N in dom0. I haven't tried it myself, though, but I will the next time I update my kernels.

[rtiangha]

This would be easier to do if you compile separate kernels for dom0 and domUs. Since the Qubes project uses a shared kernel by default, it makes it harder for them to separate them because the system was never designed to do that. But you can get around it by compiling your own kernels and varying the 'rel' attribute so that you can have multiple kernels (Package "kernel" for dom0 and "kernel-qubes-vm" for domUs) installed each compiled with a different kconfig (ex. 4.14.24-50 for dom0, 4.14.25-100 for VMs, etc). It's what I do, but that's an exercise for the reader.

I believe the Xen network backend and frontend drivers need to be enabled in dom0 in order to make the NICs visible in VMs (if that isn't the case, then please correct me!) and that, in turn, requires CONFIG_NET=y because even if you strip away all network drivers, it still needs TCP/IP socket support (i.e. CONFIG_INET) otherwise the kernel won't boot (trust me, I've tried). However, it might be possible to get away with CONFIG_ETHERNET=N in dom0. I haven't tried it myself, though, but I will the next time I update my kernels.

[DemiMarie]

I looked through the CVE list, and it is bad. Very bad. I think that we should build each kernel with the bare minimum that it needs to do its job. Only sys-net needs drivers for physical networking hardware. Only sys-usb needs a USB stack. All of them should be hardened. Furthermore, I believe that sys-net and sys-usb should be DispVMs. Especially sys-usb — I want to be able to connect a semi-trusted USB device and not worry that another USB device will compromise it.

…

On Mar 4, 2018 11:55 PM, "Reg Tiangha" ***@***.***> wrote: This would be easier to do if you compile separate kernels for dom0 and domUs. Since the Qubes project uses a shared kernel by default, it makes it harder for them to separate them because the system was never designed to do that. But you can get around it by compiling your own kernels and varying the 'rel' attribute so that you can have multiple kernels (Package "kernel" for dom0 and "kernel-qubes-vm" for domUs) installed each compiled with a different kconfig (ex. 4.14.24-50 for dom0, 4.14.25-100 for VMs, etc). It's what I do, but that's an exercise for the reader. I believe the Xen network backend and frontend drivers need to be enabled in dom0 in order to make the NICs visible in VMs (if that isn't the case, then please correct me!) and that requires CONFIG_NET=y because even if you strip away all network drivers, it still needs TCP/IP socket support (i.e. CONFIG_INET) otherwise the kernel won't boot (trust me, I've tried). However, it might be possible to get away with CONFIG_ETHERNET=N in dom0. I haven't tried it myself, though, but I will the next time I update my kernels. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3656 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWBwt1-UMsLZglsAoqr94Mo1YQ8GTAks5tbMVRgaJpZM4SbtUZ> .

[DemiMarie]

I looked through the CVE list, and it is bad. Very bad. I think that we should build each kernel with the bare minimum that it needs to do its job. Only sys-net needs drivers for physical networking hardware. Only sys-usb needs a USB stack. All of them should be hardened. Furthermore, I believe that sys-net and sys-usb should be DispVMs. Especially sys-usb — I want to be able to connect a semi-trusted USB device and not worry that another USB device will compromise it.

…

On Mar 4, 2018 11:55 PM, "Reg Tiangha" ***@***.***> wrote: This would be easier to do if you compile separate kernels for dom0 and domUs. Since the Qubes project uses a shared kernel by default, it makes it harder for them to separate them because the system was never designed to do that. But you can get around it by compiling your own kernels and varying the 'rel' attribute so that you can have multiple kernels (Package "kernel" for dom0 and "kernel-qubes-vm" for domUs) installed each compiled with a different kconfig (ex. 4.14.24-50 for dom0, 4.14.25-100 for VMs, etc). It's what I do, but that's an exercise for the reader. I believe the Xen network backend and frontend drivers need to be enabled in dom0 in order to make the NICs visible in VMs (if that isn't the case, then please correct me!) and that requires CONFIG_NET=y because even if you strip away all network drivers, it still needs TCP/IP socket support (i.e. CONFIG_INET) otherwise the kernel won't boot (trust me, I've tried). However, it might be possible to get away with CONFIG_ETHERNET=N in dom0. I haven't tried it myself, though, but I will the next time I update my kernels. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3656 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWBwt1-UMsLZglsAoqr94Mo1YQ8GTAks5tbMVRgaJpZM4SbtUZ> .

[DemiMarie]

Ideally, all of the sys-* VMs would use unikernels written in memory safe languages. But that is a long ways off.

[DemiMarie]

Ideally, all of the sys-* VMs would use unikernels written in memory safe languages. But that is a long ways off.

[marmarek]

Ideally, all of the sys-* VMs would use unikernels written in memory safe languages. But that is a long ways off.

Key word here: drivers...

As for original issue here - currently realistic solution would be to blacklist relevant drivers in dom0. Not ideal, because can easily get out of sync with actual kernel, but easy to implement with what we currently have.

[marmarek]

Ideally, all of the sys-* VMs would use unikernels written in memory safe languages. But that is a long ways off.

Key word here: drivers...

As for original issue here - currently realistic solution would be to blacklist relevant drivers in dom0. Not ideal, because can easily get out of sync with actual kernel, but easy to implement with what we currently have.

[DemiMarie]

@marmarek Yeah, drivers are the key word here. Though we can disable drivers that a domain doesn’t actually need, and minimize attack surface in userspace by using the minimum userspace we can.

[DemiMarie]

@marmarek Yeah, drivers are the key word here. Though we can disable drivers that a domain doesn’t actually need, and minimize attack surface in userspace by using the minimum userspace we can.

[DemiMarie]

@marmarek What about doing find /lib/modules/4.14.18-1.pvops.qubes.x86_64/kernel/drivers/net -delete?

[DemiMarie]

@marmarek What about doing find /lib/modules/4.14.18-1.pvops.qubes.x86_64/kernel/drivers/net -delete?