This trivial rework is aimed to reduce the amount of line changes
made by the next patch, when 'def->tpm' will become a 'def->tpms'
array.

Instead of using a 'switch' where only the VIR_DOMAIN_TPM_TYPE_EMULATOR
label does something, use an 'if' clause instead.
Tested-by: NSatheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Reviewed-by: NStefan Berger <stefanb@linux.ibm.com>
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The new name is virSecurityManagerDomainRestorePathLabel().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

After previous commit this function is used no more.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Compilers are not very good at detecting this problem. Fixed by manual
inspection of compilation warnings after replacing 'VIR_FREE' with an
empty macro.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

For the case where -fw_cfg uses a file, we need to set the
seclabels on it to allow QEMU the access. While QEMU allows
writing into the file (if specified on the command line), so far
we are enabling reading only and thus we can use read only label
(in case of SELinux).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

If built without attr support removing any image will trigger
 qemuBlockRemoveImageMetadata (the one that emits the warning)
   -> qemuSecurityMoveImageMetadata
     -> virSecurityManagerMoveImageMetadata
       -> virSecurityDACMoveImageMetadata
         -> virSecurityDACMoveImageMetadataHelper
           -> virProcessRunInFork (spawns subprocess)
             -> virSecurityMoveRememberedLabel

In there due to !HAVE_LIBATTR virFileGetXAttrQuiet will return
ENOSYS and from there the chain will error out.

That is wrong and looks like:
  libvirtd[6320]: internal error: child reported (status=125):
  libvirtd[6320]: Unable to remove disk metadata on vm testguest from
  /var/lib/uvtool/libvirt/images/testguest.qcow (disk target vda)

This change makes virSecurityDACMoveImageMetadataHelper and
virSecuritySELinuxMoveImageMetadataHelper accept that
error code gracefully and in that sense it is an extension of:
5214b2f1 "security: Don't skip label restore on file systems lacking XATTRs"
which does the same for other call chains into the virFile*XAttr functions.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The AppArmor secdriver does not use labels to grant access to
resources. Therefore, it doesn't use XATTRs and hence it lacks
implementation of .domainMoveImageMetadata callback. This leads
to a harmless but needless error message appearing in the logs:

  virSecurityManagerMoveImageMetadata:476 : this function is not
  supported by the connection driver: virSecurityManagerMoveImageMetadata

Closes: https://gitlab.com/libvirt/libvirt/-/issues/25Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

s/enther/enter/ in the function documentation.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Instead of the following pattern:

  type ret;
  ...
  ret = func();
  return ret;

we can use:

  return func()

directly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

The feature was never completed and is not really being pursued. Remove
the storage driver integration.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Catch the individual usage not removed in previous commits.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

As explained in the previous commit, we need to relabel the file
we are restoring the domain from. That is the FD that is passed
to QEMU. If the file is not under /dev then the file inside the
namespace is the very same as the one in the host. And regardless
of using transactions, the file will be relabeled. But, if the
file is under /dev then when using transactions only the copy
inside the namespace is relabeled and the one in the host is not.
But QEMU is reading from the one in the host, actually.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1772838Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This API allows drivers to separate out handling of @stdin_path
of virSecurityManagerSetAllLabel(). The thing is, the QEMU driver
uses transactions for virSecurityManagerSetAllLabel() which
relabels devices from inside of domain's namespace. This is what
we usually want. Except when resuming domain from a file. The
file is opened before any namespace is set up and the FD is
passed to QEMU to read the migration stream from. Because of
this, the file lives outside of the namespace and if it so
happens that the file is a block device (i.e. it lives under
/dev) its copy will be created in the namespace. But the FD that
is passed to QEMU points to the original living in the host and
not in the namespace. So relabeling the file inside the namespace
helps nothing.

But if we have a separate API for relabeling the restore file
then the QEMU driver can continue calling
virSecurityManagerSetAllLabel() with transactions enabled and
call this new API without transactions.

We already have an API for relabeling a single file
(virSecurityManagerDomainSetPathLabel()) but in case of SELinux
it uses @imagelabel (which allows RW access) and we want to use
@content_context (which allows RO access).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

With libpmem support compiled into qemu it will trigger the following
denials on every startup.
  apparmor="DENIED" operation="open" name="/"
  apparmor="DENIED" operation="open" name="/sys/bus/nd/devices/"

This is due to [1] that tries to auto-detect if the platform supports
auto flush for all region.

Once we know all the paths that are potentially needed if this feature
is really used we can add them conditionally in virt-aa-helper and labelling
calls in case </pmem> is enabled.

But until then the change here silences the denial warnings seen above.

[1]: https://github.com/pmem/pmdk/blob/master/src/libpmem2/auto_flush_linux.c#L131

Bug: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1871354Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: NJamie Strandboge <jamie@canonical.com>

When a QEMU process dies in the middle of a hotplug, then we fail
to restore the seclabels on the device. The problem is that if
the thread doing hotplug locks the domain object first and thus
blocks the thread that wants to do qemuProcessStop(), the
seclabel cleanup code will see vm->pid still set and mount
namespace used and therefore try to enter the namespace
represented by the PID. But the PID is gone really and thus
entering will fail and no restore is done. What we can do is to
try enter the namespace (if requested to do so) but if entering
fails, fall back to no NS mode.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1814481Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

Remove lots of stack-allocated buffers.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Our decision whether to remember seclabel for a disk image
depends on a few factors. If the image is readonly or shared or
not the chain top the remembering is suppressed for the image.
However, the virSecurityManagerSetImageLabel() is too low level
to determine whether passed @src is chain top or not. Even though
the function has the @parent argument it does not necessarily
reflect the chain top - it only points to the top level image in
the chain we want to relabel and not to the topmost image of the
whole chain. And this can't be derived from the passed domain
definition reliably neither - in some cases (like snapshots or
block copy) the @src is added to the definition only after the
operation succeeded. Therefore, introduce a flag which callers
can use to help us with the decision.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

'template' might be used uninitialized.

Use g_autofree for everything and remove all the custom labels.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

The way that our file locking works is that we open() the file we
want to lock and then use fcntl(fd, F_SETLKW, ...) to lock it.
The problem is, we are doing all of these as root which doesn't
work if the file lives on root squashed NFS, because if it does
then the open() fails. The way to resolve this is to make this a
non fatal error and leave callers deal with this (i.e. disable
remembering) - implemented in the previous commit.

https://bugzilla.redhat.com/show_bug.cgi?id=1804672Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

There are some cases where we want to remember the original owner
of a file but we fail to lock it for XATTR change (e.g. root
squashed NFS). If that is the case we error out and refuse to
start a domain. Well, we can do better if we disable remembering
for paths we haven't locked successfully.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

So far, in the lock state we are storing only the file
descriptors of the files we've locked. Therefore, when unlocking
them and something does wrong the only thing we can report is FD
number, which is not user friendly at all. But if we store paths
among with FDs we can do better error reporting.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Commit fb01e1a4 missed including virutil.h, causing the following
compilation error

../../src/security/virt-aa-helper.c:1055:43: error: implicit declaration of
function 'virHostGetDRMRenderNode' [-Werror=implicit-function-declaration]
1055 |                 char *defaultRenderNode = virHostGetDRMRenderNode();
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This module depends on domain_conf and is used directly by various
hypervisor drivers.

Move it to src/hypervisor.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Configuring vhost-user-gpu like:
    <video>
      <driver name='vhostuser'/>
      <model type='virtio' heads='1'/>
    </video>
Triggers an apparmor denial like:
    apparmor="DENIED" operation="exec" profile="libvirtd"
    name="/usr/lib/qemu/vhost-user-gpu" pid=888257 comm="libvirtd"
    requested_mask="x" denied_mask="x" fsuid=0 ouid=0

This helper is provided by qemu for vhost-user-gpu and thereby being
in the same path as qemu_bridge_helper. Due to that adding a rule allowing
to call uses the same path list.
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

When emulating smartcard with host certificates, qemu needs to
be able to read the certificates files. Add necessary code to
add the smartcard certificates file path to the apparmor profile.

Passthrough support has been tested with spicevmc and remote-viewer.

v2:
- Fix CodingStyle
- Add support for 'host' case.
- Add a comment to mention that the passthrough case doesn't need
  some configuration
- Use one rule with '{,*}' instead of two rules.
Signed-off-by: NArnaud Patard <apatard@hupstream.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Acked-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

This deletes all trace of gnulib from libvirt. We still
have the keycodemapdb submodule to deal with. The simple
solution taken was to update it when running autogen.sh.

Previously gnulib could auto-trigger refresh when running
'make' too. We could figure out a solution for this, but
with the pending meson rewrite it isn't worth worrying
about, given how infrequently keycodemapdb changes.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The configure script allows users to specify different paths for
/etc/, /usr/sbin/, /var/run/ and /usr/libexec/. Instead of
assuming user will pass expected value, generate the apparmor
profiles using the actual values.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Since a3ab6d42 "apparmor: convert libvirtd profile to a named profile"
the detection of the subelement for qemu_bridge_helper is wrong.

In combination with the older 123cc3e1 "apparmor: allow
/usr/lib/qemu/qemu-bridge-helper" it now detects qemu-bridge-helper no
more with its path, but instead as a proper subelement of the named profile
like: label=libvirtd//qemu_bridge_helper

In the same fashion the reverse rule in the qemu_bridge_helper
sub-profile still uses the path and not the named profile label.

Triggering denies like:
apparmor="DENIED" operation="file_inherit"
  profile="libvirtd//qemu_bridge_helper" pid=5629 comm="qemu-bridge-hel"
  family="unix" sock_type="stream" protocol=0 requested_mask="send receive"
  denied_mask="send receive" addr=none peer_addr=none peer="libvirtd"

This patch fixes the unix socket rules for the communication between
libvirtd and qemu-bridge-helper to match that.

Fixes: a3ab6d42
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1655111Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Also add a space after the start in some of the cases.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

At the beginning of each profile we have a comment that says when
the profile was last updated. In theory, it makes sense because
one can see immediately if they are using an outdated profile.
However, we don't do a good job in keeping the comments in sync
with reality and also sysadmins should rather use their package
manager to find out libvirt version which installed the profiles.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Acked-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

There are two more paths that we are missing in the default
domain profile: /usr/share/edk2-ovmf/ and /usr/share/sgabios/.
These exist on my Gentoo box and contain UEFI and BIOS images
respectively.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Acked-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Even though we construct a domain specific profile for each
domain we start (which should cover domain specific paths), there
is also another file that is included from the profile and which
contains domain agnostic paths (e.g. to cover libraries that qemu
links with). The paths in the file are split into blocks divided
by comments. Sort the paths in each block individually (ignoring
case sensitivity).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Acked-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

chown and some stat constants are not available on
the Windows platform.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The S_ISSOCK macro is not available on Windows platforms.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The strchrnul function doesn't exist on Windows and rather
than attempt to implement it, it is simpler to just avoid
its usage, as any callers are easily adapted.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Files inside /dev/vfio/ can't be opened more than once, meaning
that any subsequent open calls will fail. This behavior was
introduced in kernel v3.11, commit 6d6768c61b39.

When using the VFIO driver, we open a FD to /dev/vfio/N and
pass it to QEMU. If any other call attempt for the same
/dev/vfio/N happens while QEMU is still using the file, we are
unable to open it and QEMU will report -EBUSY. This can happen
if we hotplug a PCI hostdev that belongs to the same IOMMU group
of an existing domain hostdev.

The problem and solution is similar to what we already dealt
with for TPM in commit 4e95cdcb. This patch changes both
DAC and SELinux drivers to disable 'remember' for VFIO hostdevs
in virSecurityDACSetHostdevLabelHelper() and
virSecurityDACSetHostdevLabel(), and 'recall'
in virSecurityDACRestoreHostdevLabel() and
virSecuritySELinuxRestoreHostdevSubsysLabel().
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

There is a case in which we do not want 'remember' to be
set to true in SetOwnership() calls inside the
HostdevLabelHelper() functions of both DAC and SELinux drivers.
Next patch will explain and handle that scenario.

For now, let's make virSecurityDACSetOwnership() and
virSecuritySELinuxSetHostdevLabelHelper() accept a 'remember'
flag, which will be used to set the 'remember' parameter
of their respective SetOwnership() calls. No functional
change is made.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

After one of previous commits (v5.10.0-524-gce56408e) there is
a variable left unused in verify_xpath_context() which breaks the
build.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Currently, when security driver is not available users are informed that
it wasn't found which can be confusing.
1. Update error message
2. Add comment to domain doc
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by Sebastian Mitterle <smitterl@redhat.com>