[libvirt PATCH] logging: lockdown the systemd service configuration
by Daniel P. Berrangé
The 'systemd-analyze security' command looks at the unit file
configuration and reports on any settings which increase the
attack surface for the daemon. Since most systemd units are
fairly minimalist, this is generally informing us about settings
that we never put any thought into using before.
In its current configuration it reports
# systemd-analyze security virtlogd.service
...snip...
→ Overall exposure level for virtlogd.service: 9.6 UNSAFE 😨
which is pretty terrible as a score.
If we apply all of the recommendations that appear possible
without (knowingly) breaking functionality it reports:
# systemd-analyze security virtlogd.service
...snip...
→ Overall exposure level for virtlogd.service: 2.2 OK 🙂
which is a pretty decent improvement.
Some of the settings we would like to enable require a systemd
version that is newer than that available in our oldest distro
target - RHEL-8 at v239.
NB, RestrictSUIDSGID is technically newer than 239, but RHEL-8
backported it, and other distros we target have it by default.
Remaining recommendations are
✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER)
We block FOWNER/IPC_OWNER, but can't block the two DAC
capabilities. Historically apps/users might point QEMU
to log files in $HOME, pre-created with their own user
ID.
✗ IPAddressDeny=
Not required since RestrictAddressFamilies blocks IP
usage. Ignoring this avoids the overhead of creating
a traffic filter than will never be used.
✗ NoNewPrivileges=
Highly desirable, but cannot enable it yet, because it
will block the ability to transition to the virtlogd_t
SELinux domain during execve. The SELinux policy needs
fixing to permit this transition under NNP first.
✗ PrivateTmp=
There is a decent chance people have VMs configured
with a serial port logfile pointing at /tmp. We would
cause a regression to use private /tmp for logging
✗ PrivateUsers=
This would put virtlogd inside a user namespace where
its root is in fact unprivileged. Same problem as the
User= setting below
✗ ProcSubset=
Libraries we link to might read certain non-PID related
files from /proc
✗ ProtectClock=
Requires v245
✗ ProtectHome=
Same problem as PrivateTmp=. There's a decent chance
that someone has a VM configured to write a logfile
to /home
✗ ProtectHostname=
Requires v241
✗ ProtectKernelLogs
Requires v244
✗ ProtectProc
Requires v247
✗ ProtectSystem=
We only set it to 'full', as 'strict' is not viable for
our required usage
✗ RootDirectory=/RootImage=
We are not capable of running inside a custom chroot
given needs to write log files to arbitrary places
✗ RestrictAddressFamilies=~AF_UNIX
We need AF_UNIX to communicate with other libvirt daemons
✗ SystemCallFilter=~@resources
We link to libvirt.so which links to libnuma.so which has
a constructor that calls set_mempolicy. This is highly
undesirable todo during a constructor.
✗ User=/DynamicUser=
This is highly desirable, but we currently read/write
logs as root, and directories we're told to write into
could be anywhere. So using a non-root user would have
a major risk of regressions for applications and also
have upgrade implications
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/logging/virtlogd.service.in | 94 +++++++++++++++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/src/logging/virtlogd.service.in b/src/logging/virtlogd.service.in
index 8e245ddb43..9e3838ff34 100644
--- a/src/logging/virtlogd.service.in
+++ b/src/logging/virtlogd.service.in
@@ -20,5 +20,99 @@ OOMScoreAdjust=-900
# per systemd recommendations
LimitNOFILE=1024:524288
+CapabilityBoundingSet=~CAP_AUDIT_CONTROL
+CapabilityBoundingSet=~CAP_AUDIT_READ
+CapabilityBoundingSet=~CAP_AUDIT_WRITE
+CapabilityBoundingSet=~CAP_BLOCK_SUSPEND
+CapabilityBoundingSet=~CAP_CHOWN
+# Mgmt app/user might have pre-created log files that we're
+# told to open and write to, or be storing them in otherwise
+# inaccessible locations like $HOME. So we need to ignore
+# DAC permission checks.
+#CapabilityBoundingSet=~CAP_DAC_OVERRIDE
+#CapabilityBoundingSet=~CAP_DAC_READ_SEARCH
+CapabilityBoundingSet=~CAP_FOWNER
+CapabilityBoundingSet=~CAP_FSETID
+CapabilityBoundingSet=~CAP_IPC_LOCK
+CapabilityBoundingSet=~CAP_IPC_OWNER
+CapabilityBoundingSet=~CAP_KILL
+CapabilityBoundingSet=~CAP_LEASE
+CapabilityBoundingSet=~CAP_LINUX_IMMUTABLE
+CapabilityBoundingSet=~CAP_MAC_ADMIN
+CapabilityBoundingSet=~CAP_MAC_OVERRIDE
+CapabilityBoundingSet=~CAP_MKNOD
+CapabilityBoundingSet=~CAP_NET_ADMIN
+CapabilityBoundingSet=~CAP_NET_BIND_SERVICE
+CapabilityBoundingSet=~CAP_NET_BROADCAST
+CapabilityBoundingSet=~CAP_NET_RAW
+CapabilityBoundingSet=~CAP_SETFCAP
+CapabilityBoundingSet=~CAP_SETPCAP
+CapabilityBoundingSet=~CAP_SETGID
+CapabilityBoundingSet=~CAP_SETUID
+CapabilityBoundingSet=~CAP_SYSLOG
+CapabilityBoundingSet=~CAP_SYS_ADMIN
+CapabilityBoundingSet=~CAP_SYS_BOOT
+CapabilityBoundingSet=~CAP_SYS_CHROOT
+CapabilityBoundingSet=~CAP_SYS_MODULE
+CapabilityBoundingSet=~CAP_SYS_NICE
+CapabilityBoundingSet=~CAP_SYS_PACCT
+CapabilityBoundingSet=~CAP_SYS_PTRACE
+CapabilityBoundingSet=~CAP_SYS_RAWIO
+CapabilityBoundingSet=~CAP_SYS_RESOURCE
+CapabilityBoundingSet=~CAP_SYS_TIME
+CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG
+CapabilityBoundingSet=~CAP_WAKE_ALARM
+
+LockPersonality=true
+MemoryDenyWriteExecute=true
+# Cannot enable this as it prevents transitioning to
+# the confined SELinux virtlogd_t domain on execve
+# unless we modify the policy to allow this.
+#NoNewPrivileges=true
+PrivateDevices=true
+PrivateMounts=true
+PrivateNetwork=true
+# XXX someone could configure QEMU to log a serial port to an
+# arbitrary directory, including /tmp, even if this is ill-advised
+#PrivateTmp=true
+# Not until oldest build target has systemd >= v245
+#ProtectClock=true
+ProtectControlGroups=true
+# Not until oldest build target has systemd >= v241
+#ProtectHostname=true
+# Not until oldest build target has systemd >= v244
+#ProtectKernelLogs=true
+ProtectKernelModules=true
+ProtectKernelTunables=true
+# Not until oldest build target has systemd >= v247
+#ProtectProc=invisible
+ProtectSystem=full
+RestrictAddressFamilies=AF_UNIX
+RestrictNamespaces=~cgroup
+RestrictNamespaces=~ipc
+RestrictNamespaces=~mnt
+RestrictNamespaces=~net
+RestrictNamespaces=~pid
+RestrictNamespaces=~user
+RestrictNamespaces=~uts
+RestrictRealtime=true
+RestrictSUIDSGID=true
+SystemCallArchitectures=native
+SystemCallFilter=~@clock
+SystemCallFilter=~@debug
+SystemCallFilter=~@module
+SystemCallFilter=~@mount
+SystemCallFilter=~@raw-io
+SystemCallFilter=~@reboot
+SystemCallFilter=~@swap
+SystemCallFilter=~@privileged
+# Unfortunately we link to libnuma via libvirt.so which
+# has a constructor that runs unconditionally that invokes
+# set_mempolicy()
+#SystemCallFilter=~@resources
+SystemCallFilter=~@cpu-emulation
+SystemCallFilter=~@obsolete
+UMask=077
+
[Install]
Also=virtlogd.socket
--
2.41.0
1 year, 1 month
[libvirt PATCH 0/7] docs: ci: Update the CI pages with fresh contents
by Erik Skultety
While we have already descriptive articles on our GitLab CI, there's recently
been some work on the CI front where a few sections deserve some updates.
Erik Skultety (7):
docs: ci-runners: Add a note on a new runner registration process
docs: ci: Update the description on the integration CI GitLab
variables
docs: testtck: Tweak the Avocado command to run TCK test suite
docs: testtck: Improve the documentation on how to get a VM from
lcitool
docs: testing: Adjust the docs on how to run container workloads
locally
docs: testtck: Add a clear note on libvirt + Perl bindings dependency
docs: testtck: Expand the 'Run TCK' section on making use of
ci/jobs.sh
docs/ci-runners.rst | 10 ++++++++
docs/ci.rst | 8 ++++--
docs/testing.rst | 37 ++++++++++++++++++++++------
docs/testtck.rst | 60 ++++++++++++++++++++++++++++++++++++++-------
4 files changed, 96 insertions(+), 19 deletions(-)
--
2.41.0
1 year, 1 month
[PATCH] hw/rdma: Deprecate the pvrdma device and the rdma subsystem
by Thomas Huth
This subsystem is said to be in a bad shape (see e.g. [1], [2]
and [3]), and nobody seems to feel responsible to pick up patches
for this and send them via a pull request. For example there is
a patch for a CVE-worthy bug posted more than half a year ago [4]
which has never been merged.
Quoting Markus: "Given the shape it is in, I wouldn't let friends
use it in production" - we shouldn't expose this to our users in
the current state. Thus let's mark it as deprecated and finally
remove it unless somebody steps up and improves the code quality
and adds proper regression tests.
[1] https://lore.kernel.org/qemu-devel/20230918144206.560120-1-armbru@redhat....
[2] https://lore.kernel.org/qemu-devel/ZQnojJOqoFu73995@redhat.com/
[3] https://lore.kernel.org/qemu-devel/1054981c-e8ae-c676-3b04-eeb030e11f65@t...
[4] https://lore.kernel.org/qemu-devel/20230301142926.18686-1-yuval.shaia.ml@...
[5] https://lore.kernel.org/qemu-devel/8734z9f086.fsf@pond.sub.org/
Signed-off-by: Thomas Huth <thuth(a)redhat.com>
---
MAINTAINERS | 2 +-
docs/about/deprecated.rst | 8 ++++++++
hw/rdma/vmw/pvrdma_main.c | 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 355b1960ce..ca42b89ef8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3815,7 +3815,7 @@ F: docs/block-replication.txt
PVRDMA
M: Yuval Shaia <yuval.shaia.ml(a)gmail.com>
M: Marcel Apfelbaum <marcel.apfelbaum(a)gmail.com>
-S: Maintained
+S: Odd Fixes
F: hw/rdma/*
F: hw/rdma/vmw/*
F: docs/pvrdma.txt
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index dc4da95329..f0c7addb1f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -365,6 +365,14 @@ QEMU's ``vhost`` feature, which would eliminate the high latency costs under
which the 9p ``proxy`` backend currently suffers. However as of to date nobody
has indicated plans for such kind of reimplementation unfortunately.
+``-device pvrdma`` and the rdma subsystem (since 8.2)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The pvrdma device and the whole rdma subsystem are in a bad shape and
+without active maintenance. The QEMU project intends to remove this
+device and subsystem from the code base in a future release without
+replacement unless somebody steps up and improves the situation.
+
Block device options
''''''''''''''''''''
diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c
index 4fc6712025..ed49ce1e72 100644
--- a/hw/rdma/vmw/pvrdma_main.c
+++ b/hw/rdma/vmw/pvrdma_main.c
@@ -601,6 +601,8 @@ static void pvrdma_realize(PCIDevice *pdev, Error **errp)
bool ram_shared = false;
PCIDevice *func0;
+ warn_report_once("pvrdma is deprecated and will be removed in a future release");
+
rdma_info_report("Initializing device %s %x.%x", pdev->name,
PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
--
2.41.0
1 year, 1 month
The attached virtio disk is not recognized by libvirt but it is recognized by qemu
by Mario Marietto
Hello.
I'm trying to virtualize FreeBSD 13.2 for arm 32 bit on my laptop ARM
Chromebook where qemu is version 5.1,KVM is enabled,libvirt and
virt-manager are installed from the source code and everything works great.
The host OS is Devuan 5. Infact,using these parameters,FreeBSD is able to
boot entirely :
UEFICODE=/usr/share/AAVMF/AAVMF32_CODE.fd
UEFIVARS=/usr/share/AAVMF/AAVMF32_VARS.fd
DISK=/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img
qemu-system-arm -enable-kvm -serial stdio -m 1024 -M virt -cpu cortex-a15
-drive if=pflash,format=raw,unit=0,file=$UEFICODE
-drive if=pflash,format=raw,unit=1,file=$UEFIVARS
-drive file=$DISK,media=disk,format=raw
-device i82559b,netdev=net0,mac="52:54:00:12:34:55"
-netdev type=user,id=net0 -device virtio-gpu-pci -usb
-device nec-usb-xhci -device usb-kbd -device usb-mouse
-device vmware-svga,id=video0,vgamem_mb=16
As you can see from this boot log messages :
https://pastebin.ubuntu.com/p/VBtJ5bTTCz/
So,this argument is good because qemu recognizes the virtio disk :
-drive file=$DISK,media=disk,format=raw \
but these arguments used by libvirt aren't able to boot FreeBSD because the
virtio disk attached is not recognized (I also tried with a SATA disk and
it is not recognized as well) :
<disk type="file" device="disk">
<driver name="qemu" type="raw"/>
<source file="/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img"/>
<target dev="vda" bus="virtio"/>
<address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
</disk>
Here you can see what are the full XML code used by libirt :
https://pastebin.ubuntu.com/p/hpGmgp2773/
this is the portion of code that correspond with the virtio disk (the
FreeBSD image file)
[image: 1] <https://i.stack.imgur.com/NUWg7.png>
What's the difference between the qemu and the libvirt parameters ? Do you
have some vague idea about the reason ? I think the problem is caused by
qemu and/or libvirt.
I tried to boot the image going inside the bios settings and trying to boot
directly the image disk,but I saw this error :
[image: 2] <https://i.stack.imgur.com/rdYGs.png>
If you want to see the whole boot sequence,you can give a look at this
short video that I have recorded :
https://drive.google.com/file/d/1kRoAFH_6DH-vNEmNmg4PEQ8lQmKZnUi2/view
--
Mario.
1 year, 1 month
[libvirt PATCH] qemu: DomainGetGuestVcpusParams: reduce scope of tmp
by Ján Tomko
Wrap the macro body in a new block and move the declaration of 'tmp'
into it, to avoid the need to mix g_autofree with manual freeing.
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
src/qemu/qemu_driver.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 056b5cec98..f3c9730cd8 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -18396,7 +18396,6 @@ qemuDomainGetGuestVcpusParams(virTypedParameterPtr *params,
g_autoptr(virBitmap) vcpus = virBitmapNew(QEMU_GUEST_VCPU_MAX_ID);
g_autoptr(virBitmap) online = virBitmapNew(QEMU_GUEST_VCPU_MAX_ID);
g_autoptr(virBitmap) offlinable = virBitmapNew(QEMU_GUEST_VCPU_MAX_ID);
- g_autofree char *tmp = NULL;
size_t i;
int ret = -1;
@@ -18416,11 +18415,13 @@ qemuDomainGetGuestVcpusParams(virTypedParameterPtr *params,
}
#define ADD_BITMAP(name) \
- if (!(tmp = virBitmapFormat(name))) \
- goto cleanup; \
- if (virTypedParamsAddString(&par, &npar, &maxpar, #name, tmp) < 0) \
- goto cleanup; \
- VIR_FREE(tmp)
+ do { \
+ g_autofree char *tmp = NULL; \
+ if (!(tmp = virBitmapFormat(name))) \
+ goto cleanup; \
+ if (virTypedParamsAddString(&par, &npar, &maxpar, #name, tmp) < 0) \
+ goto cleanup; \
+ } while (0)
ADD_BITMAP(vcpus);
ADD_BITMAP(online);
--
2.41.0
1 year, 1 month
Fwd: Hexdump0815 support for kvm and an important question (Was: Re: New thread...)
by Mario Marietto
Hello to everyone.
I'm trying to virtualize FreeBSD 13.2 for arm 32 bit on my laptop ARM
Chromebook where KVM is enabled,libvirt and virt-manager are installed from
the source code and everything work great. The Host OS is Devuan 5. Infact
, using these qemu parameters,FreeBSD is able to boot entirely :
DISK=/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img
qemu-system-arm \
-enable-kvm -serial stdio \
-m 1024 -M virt -cpu cortex-a15 \
-drive if=pflash,format=raw,unit=0,file=$UEFICODE \
-drive if=pflash,format=raw,unit=1,file=$UEFIVARS \
-drive file=$DISK,media=disk,format=raw \
-device i82559b,netdev=net0,mac="52:54:00:12:34:55" \
-netdev type=user,id=net0 \
-device virtio-gpu-pci \
-usb -device nec-usb-xhci \
-device usb-kbd -device usb-mouse \
-device vmware-svga,id=video0,vgamem_mb=16
*As you can see from this boot log messages :*
https://pastebin.ubuntu.com/p/DWggdRRxVv/
*So,this argument is good :*
-drive file=$DISK,media=disk,format=raw \
*but these arguments used by libvirt aren't able to boot FreeBSD
because the virtio disk attached is not recognized (I also tried with
a SATA disk and it is not regognized as well) :*
<disk type="file" device="disk">
<driver name="qemu" type="raw"/>
<source file="/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img"/>
<target dev="vda" bus="virtio"/>
<address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
</disk>
*as you can see :*
[image: Screenshot_2023-09-29_10-44-06.png]
What's the difference ? Do you have some vague idea about the reason ? I
don't know if the cause is related to libvirt or to FreeBSD,so I'm trying
to exclude one of these.
--
Mario.
1 year, 1 month
[PATCH] qemu: Add VIR_FREE in ADD_BITMAP
by Anastasia Belova
virBitmapFormat returns the string that should be freed.
All strings in three ADD_BITMAP calls in qemuDomainGetGuestVcpusParams
are contained in tmp. So memory leak is possible here without VIR_FREE.
Fixes: 3e7db8d3e8 ("Remove backslash alignment attempts")
Signed-off-by: Anastasia Belova <abelova(a)astralinux.ru>
---
src/qemu/qemu_driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 9e0f204e44..a70bfb6450 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -18420,6 +18420,7 @@ qemuDomainGetGuestVcpusParams(virTypedParameterPtr *params,
goto cleanup; \
if (virTypedParamsAddString(&par, &npar, &maxpar, #name, tmp) < 0) \
goto cleanup; \
+ VIR_FREE(tmp); \
ADD_BITMAP(vcpus);
ADD_BITMAP(online);
--
2.30.2
1 year, 1 month
[PATCH] NEWS: Document my contributions for upcoming release
by Michal Privoznik
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
NEWS.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index c17a1d002d..6f46e86ba8 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -43,8 +43,20 @@ v9.8.0 (unreleased)
stability of qemu. Therefore, when available, libvirt will use nbdkit as a
backend for these network disks and export an NBD disk to qemu.
+ * virnetdevopenvswitch: Propagate OVS error messages
+
+ When configuring OVS interfaces/bridges libvirt used to report its own
+ error messages instead of passing (more accurate) error messages from
+ `ovs-vsctl`. This is now changed.
+
* **Bug fixes**
+ * Various virtio-mem/virtio-pmem fixes
+
+ It was discovered that libvirt did not validate some values wrt virtio-mem
+ and virtio-pmem memory devices, e.g. overlapping memory addresses or
+ alignment.
+
v9.7.0 (2023-09-01)
===================
--
2.41.0
1 year, 1 month
[PATCH] NEWS: Fix placement of network metadata entry
by Michal Privoznik
The network metadata support is a new feature in the upcoming
release, not a removed one. Place it accordingly.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
NEWS.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/NEWS.rst b/NEWS.rst
index 768e6fc326..c17a1d002d 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -15,14 +15,14 @@ v9.8.0 (unreleased)
* **Removed features**
+* **New features**
+
* network: New metadata change event
The network object now has a new event ID ``VIR_NETWORK_EVENT_ID_METADATA_CHANGE``
that can be used to get notifications upon changes in any of ``<title>``,
``<description>`` or ``<metadata>``.
-* **New features**
-
* qemu: Add support for vDPA block devices
With a new enough version of qemu, libvirt will allow you to assign vDPA block
--
2.41.0
1 year, 1 month
Entering freeze for libvirt-9.8.0
by Jiri Denemark
I have just tagged v9.8.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://download.libvirt.org/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Thanks,
Jirka
1 year, 1 month
