We mirror the labeling strategy that was used for its top image
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will be used for recursing into externalDataStore
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Rename the existing virSecuritySELinuxRestoreImageLabelInt
to virSecuritySELinuxRestoreImageLabelSingle, and extend the new
ImageLabelInt handle externalDataStore
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will simplify future patches and make the logic easier to follow
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The only caller always passes in a non-null parent
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
All the SetFileCon calls only differ by the label they pass in.
Rework the conditionals to track what label we need, and use a
single SetFileCon call
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We mirror the labeling strategy that was used for its sibling
image
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will be used for recursing into externalDataStore
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Rename the existing virSecurityDACRestoreImageLabelInt
to virSecurityDACRestoreImageLabelSingle, and extend the new
ImageLabelInt handle externalDataStore
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will simplify future patches and make the logic easier to follow
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The only caller always passes in a non-null parent
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1755803
The /dev/tpmN file can be opened only once, as implemented in
drivers/char/tpm/tpm-dev.c:tpm_open() from the kernel's tree. Any
other attempt to open the file fails. And since we're opening the
file ourselves and passing the FD to qemu we will not succeed
opening the file again when locking it for seclabel remembering.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
While in most cases we want to remember/recall label for a
chardev, there are some special ones (like /dev/tpm0) where we
don't want to remember the seclabel nor recall it. See next
commit for rationale behind.
While the easiest way to implement this would be to just add new
argument to virSecurityDACSetChardevLabel() this one is also a
callback for virSecurityManagerSetChardevLabel() and thus has
more or less stable set of arguments. Therefore, the current
virSecurityDACSetChardevLabel() is renamed to
virSecurityDACSetChardevLabelHelper() and the original function
is set to call the new one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
So far all items on the chown/setfilecon list have the same
.remember value. But this will change shortly. Therefore, don't
try to lock paths which we won't manipulate XATTRs for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
On Fedora, already whitelisted paths to AAVMF and OVMF binaries
are symlinks to binaries under /usr/share/edk2/. Add that directory
to the RO whitelist so virt-aa-helper-test passes
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will simplify adding support for qcow2 external data_file
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is closer to what security_selinux.c does, and will help add
support for qcow2 external data_files
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This mirrors the code layout in security_selinux.c. It will also make
it easier to share the checks for qcow2 external data_file support
eventually
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The virStorageSource must have everything it needs
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
There's only one caller, so open code the file_add_path behavior
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
true is always passed here, so delete the unused code path and
adjust the associated comment
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It is the only user. Rename it to match the local style
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The AppArmor profile generated by virt-aa-helper is too strict for swtpm.
This change contains 2 small fixes:
- Relax append access to swtpm's log file to permit write access instead.
Append access is insufficient because the log is opened with O_CREAT.
- Permit swtpm to acquire a lock on its lock file.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Neither virThreadInitialize or virThreadOnExit do anything since we
dropped the Win32 threads impl, in favour of win-pthreads with:
commit 0240d94c36
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed Jan 22 16:17:10 2014 +0000
Remove windows thread implementation in favour of pthreads
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
AppArmorGetSecurityProcessLabel copies the VM's profile name to the
label member of virSecurityLabel struct. If the profile is not loaded,
the name is set empty before calling virStrcpy to copy it. However,
virStrcpy will fail if src is empty (0 length), causing
AppArmorGetSecurityProcessLabel to needlessly fail. Simple operations
that report security driver information will subsequently fail
virsh dominfo test
Id: 248
Name: test
...
Security model: apparmor
Security DOI: 0
error: internal error: error copying profile name
Avoid copying an empty profile name when the profile is not loaded.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The Perl bindings for libvirt use the test driver for unit tests. This
tries to load the cpu_map/index.xml file, and when run from an
uninstalled build will fail.
The problem is that virFileActivateDirOverride is called by our various
binaries like libvirtd, virsh, but is not called when a 3rd party app
uses libvirt.so
To deal with this we allow the LIBVIRT_DIR_OVERRIDE=1 env variable to be
set and make virInitialize look for this. The 'run' script will set it,
so now build using this script to run against an uninstalled tree we
will correctly resolve files to the source tree.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
I guess the reason for that was the automatic interpretation/stringification of
setfilecon_errno, but the code was not nice to read and it was a bit confusing.
Also, the logs and error states get cleaner this way.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
There are some network file systems that do support XATTRs (e.g.
gluster via FUSE). And they appear to support SELinux too.
However, not really. Problem is, that it is impossible to change
SELinux label of a file stored there, and yet we claim success
(rightfully - hypervisor succeeds in opening the file). But this
creates a problem for us - from XATTR bookkeeping POV, we haven't
changed the label and thus if we remembered any label, we must
roll back and remove it.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1740506
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This function is no longer needed because after previous commits
it's just an alias to virSecuritySELinuxSetFilecon.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Now, that we don't need to remember if setting context is
'optional' (the argument only made
virSecuritySELinuxSetFileconImpl() return a different success
code), we can drop it from the _virSecuritySELinuxContextItem
structure as we don't need to remember it in transactions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
There is no real difference between
virSecuritySELinuxSetFilecon() and
virSecuritySELinuxSetFileconOptional(). Drop the latter in favour
of the former.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The only thing that the @optional argument does is that it makes
the function return 1 instead of 0 if setting SELinux context
failed in a non-critical fashion. Drop the argument then and
return 1 in that case. This enables caller to learn if SELinux
context was set or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
After 7cfb7aab57 commit starting a domain pullutes logs with
warnings like [1]. The reason is resource files do not
have timestamp before starting a domain and after destroying
domain the timestamp is cleared. Let's check the timestamp
only if attribute with refcounter is found.
[1] warning : virSecurityValidateTimestamp:198 : Invalid XATTR timestamp detected on \
/some/path secdriver=dac
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
All code using LOCALSTATEDIR "/run" is updated to use RUNSTATEDIR
instead. The exception is the remote driver client which still
uses LOCALSTATEDIR "/run". The client needs to connect to remote
machines which may not be using /run, so /var/run is more portable
due to the /var/run -> /run symlink.
Some duplicate paths in the apparmor code are also purged.
There's no functional change by default yet since both expressions
expand to the same value.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It may happen that we leave some XATTRs behind. For instance, on
a sudden power loss, the host just shuts down without calling
restore on domain paths. This creates a problem, because when the
host starts up again, the XATTRs are there but they don't reflect
the true state and this may result in libvirt denying start of a
domain.
To solve this, save a unique timestamp (host boot time) among
with our XATTRs.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1741140
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
If user has two domains, each have the same disk (configured for
RW) but each runs with different seclabel then we deny start of
the second domain because in order to do that we would need to
relabel the disk but that would cut the first domain off. Even if
we did not do that, qemu would fail to start because it would be
unable to lock the disk image for the second time. So far, this
behaviour is expected. But what is not expected is that we
increase the refcounter in XATTRs and leave it like that.
What happens is that when the second domain starts,
virSecuritySetRememberedLabel() is called, and since there are
XATTRs from the first domain it increments the refcounter and
returns it (refcounter == 2 at this point). Then callers
(virSecurityDACSetOwnership() and
virSecuritySELinuxSetFileconHelper()) realize that refcounter is
greater than 1 and desired seclabel doesn't match the one the
disk image already has and an error is produced. But the
refcounter is never decremented.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1740024
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Apparently /proc/self is automatically converted to /proc/@{pid}
before checking rules, which makes spelling it out explicitly
redundant.
Suggested-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Since
commit 432faf259b
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Tue Jul 2 19:49:51 2019 +0200
virCommand: use procfs to learn opened FDs
When spawning a child process, between fork() and exec() we close
all file descriptors and keep only those the caller wants us to
pass onto the child. The problem is how we do that. Currently, we
get the limit of opened files and then iterate through each one
of them and either close() it or make it survive exec(). This
approach is suboptimal (although, not that much in default
configurations where the limit is pretty low - 1024). We have
/proc where we can learn what FDs we hold open and thus we can
selectively close only those.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
v5.5.0-173-g432faf259b
programs using the virCommand APIs on Linux need read access to
/proc/self/fd, or they will fail like
error : virCommandWait:2796 : internal error: Child process
(LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c
-u libvirt-b20e9a8e-091a-45e0-8823-537119e98bc6) unexpected exit
status 1: libvirt: error : cannot open directory '/proc/self/fd':
Permission denied
virt-aa-helper: error: apparmor_parser exited with error
Update the AppArmor profile for virt-aa-helper so that read access
to the relevant path is granted.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way we're processing the return status, using WIFEXITED() and
friends, only works when we have the raw return status; however,
virCommand defaults to processing the return status for us. Call
virCommandRawStatus() before virCommandRun() so that we get the raw
return status and the logic can actually work.
This results in guest startup failures caused by AppArmor issues
being reported much earlier: for example, if virt-aa-helper exits
with an error we're now reporting
error: internal error: cannot load AppArmor profile 'libvirt-b20e9a8e-091a-45e0-8823-537119e98bc6'
instead of the misleading
error: internal error: Process exited prior to exec: libvirt:
error : unable to set AppArmor profile 'libvirt-b20e9a8e-091a-45e0-8823-537119e98bc6'
for '/usr/bin/qemu-system-x86_64': No such file or directory
Suggested-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Right now we're using the virRun() convenience API, but that
doesn't allow the kind of control we want. Use the virCommand
APIs directly instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If there are two paths on the list that are the same we need to
lock it only once. Because when we try to lock it the second time
then open() fails. And if it didn't, locking it the second time
would fail for sure. After all, it is sufficient to lock all
paths just once satisfy the caller.
Reported-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Document why we need to sort paths while it's still fresh in my
memory.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
VHD images can be used as any other, so we should add them to the list
of types that virt-aa-helper can read when creating the per-guest rules
for backing files.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
A simple helper function that would be used from DAC and SELinux
drivers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The purpose of this API is to allow caller move XATTRs (or remove
them) from one file to another. This will be needed when moving
top level of disk chain (either by introducing new HEAD or
removing it).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This effectively reverts d7420430ce and adds new code.
Here is the problem: Imagine a file X that is to be shared
between two domains as a disk. Let the first domain (vm1) have
seclabel remembering turned on and the other (vm2) has it turned
off. Assume that both domains will run under the same user, but
the original owner of X is different (i.e. trying to access X
without relabelling leads to EPERM).
Let's start vm1 first. This will cause X to be relabelled and to
gain new attributes:
trusted.libvirt.security.ref_dac="1"
trusted.libvirt.security.dac="$originalOwner"
When vm2 is started, X will again be relabelled, but since the
new label is the same as X already has (because of vm1) nothing
changes and vm1 and vm2 can access X just fine. Note that no
XATTR is changed (especially the refcounter keeps its value of 1)
because the vm2 domain has the feature turned off.
Now, vm1 is shut off and vm2 continues running. In seclabel
restore process we would get to X and since its refcounter is 1
we would restore the $originalOwner on it. But this is unsafe to
do because vm2 is still using X (remember the assumption that
$originalOwner and vm2's seclabel are distinct?).
The problem is that refcounter stored in XATTRs doesn't reflect
the actual times a resource is in use. Since I don't see any easy
way around it let's just not store original owner on shared
resources. Shared resource in world of domain disks is:
- whole backing chain but the top layer,
- read only disk (we don't require CDROM to be explicitly
marked as shareable),
- disk marked as shareable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Just like previous commit allowed to enable or disable owner
remembering for each individual path, do the same for SELinux
driver. This is going to be needed in the next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
One caller in particular (virSecurityDACSetImageLabelInternal)
will want to have the feature turned on only in some cases.
Introduce @remember member to _virSecurityDACChownItem to track
whether caller wants to do owner remembering or not.
The actual remembering is then enabled if both caller wanted it
and the feature is turned on in the config file.
Technically, we could skip over paths that don't have remember
enabled when creating a list of paths to lock. We won't touch
their XATTRs after all. Well, I rather play it safe and keep them
on the locking list for now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Both DAC and SELinux drivers support transactions. Each item on
the transaction list consists of various variables and @restore
is one of them. Document it so that as the list of variables grow
it's easier to spot which variable does what.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The way that virSecurityDACRecallLabel is currently written is
that if XATTRs are not supported for given path to the caller
this is not different than if the path is still in use. The value
of 1 is returned which makes secdrivers skip label restore.
This is clearly a bug as we are not restoring labels on say NFS
even though previously we were.
Strictly speaking, changes to virSecurityDACRememberLabel are not
needed, but they are done anyway so that getter and setter behave
in the same fashion.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The way that security drivers use XATTR is kind of verbose. If
error reporting was left for caller then the caller would end up
even more verbose.
There are two places where we do not want to report error if
virFileGetXAttr fails. Therefore virFileGetXAttrQuiet is
introduced as an alternative that doesn't report errors.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Just like it's DAC counterpart is doing,
virSecuritySELinuxRestoreAllLabel() could print @migrated in the
debug message.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Commit a3ab6d42 changed the libvirtd profile to a named profile
but neglected to accommodate the change in the qemu profile
ptrace and signal rules.
Later on 4ec3cf9a fixed that for ptrace and signal but openGraphicsFD
is still missing.
As a result, libvirtd is unable to open UI on libvirt >=5.1 e.g. with
virt-manager.
Add openGraphicsFD rule that references the libvirtd profile
by name in addition to full binary path.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1833040
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Various binaries are statically linking to libvirt_util.la and
other intermediate libraries we build. These intermediate libs
all get built into the main libvirt.so shared library eventually,
so we can dynamically link to that instead and reduce the on disk
footprint.
In libvirt-daemon RPM:
virtlockd: 1.6 MB -> 153 KB
virtlogd: 1.6 MB -> 157 KB
libvirt_iohelper: 937 KB -> 23 KB
In libvirt-daemon-driver-network RPM:
libvirt_leaseshelper: 940 KB -> 26 KB
In libvirt-daemon-driver-storage-core RPM:
libvirt_parthelper: 926 KB -> 21 KB
IOW, about 5.6 MB total space saving in a build done on Fedora 30
x86_64 architecture.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When a vhost scsi device is hotplugged virt-aa-helper is called to
add the respective path.
For example the config:
<hostdev mode='subsystem' type='scsi_host' managed='no'>
<source protocol='vhost' wwpn='naa.50014059de6fba4f'/>
</hostdev>
Will call it to add:
/sys/kernel/config/target/vhost//naa.50014059de6fba4f
But in general /sys paths are filtered in virt-aa-helper.c:valid_path
To allow the path used for vhost-scsi we need to add it to the list of
known and accepted overrides.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1829223
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This requires drivers to opt in to handle the raw modelstr
network model, all others will error if a passed in XML value
is not in the model enum.
Enable this feature for libxl/xen/xm and qemu drivers
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
To ease converting the net->model value to an enum, add
the wrapper functions:
virDomainNetGetModelString
virDomainNetSetModelString
virDomainNetStreqModelString
virDomainNetStrcaseeqModelString
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We're setting seclabels on unix sockets but never restoring them.
Surprisingly, we are doing so in SELinux driver.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Vim has trouble figuring out the filetype automatically because
the name doesn't follow existing conventions; annotations like
the ones we already have in Makefile.ci help it out.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit a5e1602090.
Getting rid of unistd.h from our headers will require more work than
just fixing the broken mingw build. Revert it until I have a more
complete proposal.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
util/virutil.h bogously included unistd.h. Drop it and replace it by
including it directly where needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The d_type field cannot be assumed to be filled. Some filesystems, such
as older XFS, will simply report DT_UNKNOWN.
Even if the d_type is filled in, the use of it in the SELinux functions
is dubious. If labelling all files in a directory there's no reason to
skip things which are not regular files. We merely need to skip "." and
"..", which is done by virDirRead() already.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add hppa, nios2, or1k, riscv32 and riscv64 to the profile.
Fixes: https://bugs.debian.org/914940
Signed-off-by: intrigeri <intrigeri@boum.org>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Commit a3ab6d42 changed the libvirtd profile to a named profile,
breaking the apparmor driver's ability to detect if the profile is
active. When the apparmor driver loads it checks the status of the
libvirtd profile using the full binary path, which fails since the
profile is now referenced by name. If the apparmor driver is
explicitly requested in /etc/libvirt/qemu.conf, then libvirtd fails
to load too.
Instead of only checking the profile status by full binary path,
also check by profile name. The full path check is retained in case
users have a customized libvirtd profile with full path.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Commit a3ab6d42 changed the libvirtd profile to a named profile
but neglected to accommodate the change in the qemu profile
ptrace and signal rules. As a result, libvirtd is unable to
signal confined qemu processes and hence unable to shutdown
or destroy VMs.
Add ptrace and signal rules that reference the libvirtd profile
by name in addition to full binary path.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Further testing with more devices showed that we sometimes have a
different depth of pci device paths when accessing sysfs for device
attributes.
But since the access is limited to a set of filenames and read only it
is safe to use a wildcard for that.
Related apparmor denies - while we formerly had only considered:
apparmor="DENIED" operation="open"
name="/sys/devices/pci0000:00/0000:00:02.1/uevent"
requested_mask="r"
We now also know of cases like:
apparmor="DENIED" operation="open"
name="/sys/devices/pci0000:00/0000:00:03.1/0000:1c:00.0/uevent"
requested_mask="r"
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1817943
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Further testing with different devices showed that we need more rules
to drive gl backends with nvidia cards. Related denies look like:
apparmor="DENIED" operation="open"
name="/usr/share/egl/egl_external_platform.d/"
requested_mask="r"
apparmor="DENIED" operation="open"
name="/proc/modules"
requested_mask="r"
apparmor="DENIED" operation="open"
name="/proc/driver/nvidia/params"
requested_mask="r"
apparmor="DENIED" operation="mknod"
name="/dev/nvidiactl"
requested_mask="c"
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1817943
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled
graphics devices" implemented the detection for gl enabled
devices in virt-aa-helper. But further testing showed
that it will need much more access for the full gl stack
to work.
Upstream apparmor just recently split those things out and now
has two related abstractions at
https://gitlab.com/apparmor/apparmor/blob/master:
- dri-common at /profiles/apparmor.d/abstractions/dri-common
- mesa: at /profiles/apparmor.d/abstractions/mesa
If would be great to just include that for the majority of
rules, but they are not yet in any distribution so we need
to add rules inspired by them based on the testing that we
can do.
Furthermore qemu with opengl will also probe the backing device
of the rendernode for attributes which should be safe as
read-only wildcard rules.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Change fb01e1a44 "virt-aa-helper: generate rules for gl enabled
graphics devices" implemented the detection for gl enabled
devices in virt-aa-helper. But it will in certain cases e.g. if
no rendernode was explicitly specified need to read /dev/dri
which it currently isn't allowed.
Add a rule to the apparmor profile of virt-aa-helper itself to
be able to do that.
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
We dropped support in commit 8e91a40 (November 2015), but some
occurrences still remained, even in live code.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reported-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The default permissions (0600 root:root) are of no use to the qemu
process so we need to change the owner to qemu iff running with
namespaces.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we have replacement in the form of the image labeling function
we can drop the unnecessary functions by replacing all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Security labeling of disks consists of labeling of the disk image
itself and it's backing chain. Modify
virSecurityManager[Set|Restore]ImageLabel to take a boolean flag that
will label the full chain rather than the top image itself.
This allows to delete/unify some parts of the code and will also
simplify callers in some cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We have this very handy macro called VIR_STEAL_PTR() which steals
one pointer into the other and sets the other to NULL. The
following coccinelle patch was used to create this commit:
@ rule1 @
identifier a, b;
@@
- b = a;
...
- a = NULL;
+ VIR_STEAL_PTR(b, a);
Some places were clean up afterwards to make syntax-check happy
(e.g. some curly braces were removed where the body become a one
liner).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This will be extended in the future, so let's simplify things by
centralizing the checks.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Upstream apparmor is switching to named profiles. In short,
/usr/sbin/dnsmasq {
becomes
profile dnsmasq /usr/sbin/dnsmasq {
Consequently, any profiles that reference profiles in a peer= condition
need to be updated if the referenced profile switches to a named profile.
Apparmor commit 9ab45d81 switched dnsmasq to a named profile. ATM it is
the only named profile switch that has affected libvirt. Add rules to the
libvirtd profile to reference dnsmasq in peer= conditions by profile name.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
This adds the virt-aa-helper support for gl enabled graphics devices to
generate rules for the needed rendernode paths.
Example in domain xml:
<graphics type='spice'>
<gl enable='yes' rendernode='/dev/dri/bar'/>
</graphics>
results in:
"/dev/dri/bar" rw,
Special cases are:
- multiple devices with rendernodes -> all are added
- non explicit rendernodes -> follow recently added virHostGetDRMRenderNode
- rendernode without opengl (in egl-headless for example) -> still add
the node
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1757085
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
These files need to be installed on the system for apparmor
support to work, so they don't belong with examples.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The @con type security_context_t is actually a "char *", so the
correct check should be to dereference one more level; otherwise,
we could return/use the NULL pointer later in a subsequent
virSecuritySELinuxSetFileconImpl call (using @fcon).
Suggested-by: Michal Prívozník <mprivozn@redhat.com>
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If virSecuritySELinuxRestoreFileLabel returns 0 or -1 too soon, then
the @newpath will be leaked.
Suggested-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We are setting label on kernel, initrd, dtb and slic_table files.
But we never restored it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It helps whe trying to match calls with virSecuritySELinuxSetAllLabel
if the order in which devices are set/restored is the same in
both functions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When iterating over list of paths/disk sources to relabel it may
happen that the process fails at some point. In that case, for
the sake of keeping seclabel refcount (stored in XATTRs) in sync
with reality we have to perform rollback. However, if that fails
too the only thing we can do is warn user.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's important to keep XATTRs untouched (well, in the same state
they were in when entering the function). Otherwise our
refcounting would be messed up.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to what I did in DAC driver, this also requires the
same SELinux label to be used for shared paths. If a path is
already in use by a domain (or domains) then and the domain we
are starting now wants to access the path it has to have the same
SELinux label. This might look too restrictive as the new label
can still guarantee access to already running domains but in
reality it is very unlikely and usually an admin mistake.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It is going to be important to know if the current transaction we
are running is a restore operation or set label operation so that
we know whether to call virSecurityGetRememberedLabel() or
virSecuritySetRememberedLabel(). That is, whether we are in a
restore and therefore have to fetch the remembered label, or we
are in set operation and therefore have to store the original
label.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we have seclabel remembering we can safely restore
labels for shared and RO disks. In fact we need to do that to
keep seclabel refcount stored in XATTRs in sync with reality.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This also requires the same DAC label to be used for shared
paths. If a path is already in use by a domain (or domains) then
and the domain we are starting now wants to access the path it
has to have the same DAC label. This might look too restrictive
as the new label can still guarantee access to already running
domains but in reality it is very unlikely and usually an admin
mistake.
This requirement also simplifies seclabel remembering, because we
can store only one seclabel and have a refcounter for how many
times the path is in use. If we were to allow different labels
and store them in some sort of array the algorithm to match
labels to domains would be needlessly complicated.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Because the implementation that will be used for label
remembering/recall is not atomic we have to give callers a chance
to enable or disable it. That is, enable it if and only if
metadata locking is enabled. Otherwise the feature MUST be turned
off.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We are setting label on kernel, initrd, dtb and slic_table files.
But we never restored it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It helps whe trying to match calls with virSecurityDACSetAllLabel
if the order in which devices are set/restored is the same in
both functions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
