This bug was fixed in the package libvirt - 5.0.0-1ubuntu4
---
libvirt (5.0.0-1ubuntu4) eoan; urgency=medium
* d/p/ubuntu/lp-1825195-*.patch: fix issues with old guests that defined
the never functional osxsave and ospke features (LP: #1825195).
* d/p/series: reorder ubuntu De
This issue is different, and so will be the solution.
I have separated the work on the vhost-scsi hotplug case into bug 1829223
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815910
Title:
Apparmor
With vhost fix:
Host:
Guest:
[ 915.674097] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0,
erc=4, rsid=4
[ 915.674230] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0,
erc=4, rsid=0
[ 915.713074] NET: Registered protocol family 40
This has the same "dac would prevent i
Since quite often hot/clodplug is different I was looking into that as
well:
$ cat vhost-scsi.xml
$ virsh attach-device disco-luks vhost-scsi.xml
error: internal error: cannot update AppArmor profile
'libvirt-0804001f-c45f-4345-994f-9fec048e822e'
$ cat vhost-vsock.xml
vhost_scsi would be like:
#1 making the module available:
$ sudo modprobe vhost_scsi
#2 some prework to set things up [1]
My disk:
/dev/disk/by-path/ccw-0.0.e000-fc-0x50050763060b16b6-lun-0x4024400a
$ sudo targetcli
targetcli shell version 2.1.fb48
Copyright 2011-2013 by Datera, Inc an
I checked vsock devices, those are fully mediated by libvirt and only an
already open FD is passed when using those.
Without apparmor allowing a new open to qemu I have:
sudo lsof -p 9445 +fg | grep vhost
qemu-syst 9445 libvirt-qemu 19u CHR RW,LG 10,241
0t0
I think they vhost_scsi might be covered by AppArmorSetSecurityHostLabel adding
the rule as needed.
I'm not so sure on vhost_vsock.
Certainly worth to come up with a few tests and ensure that is true for all
early/late access cases when implementing this.
--
You received this bug notification b
I would also consider vhost_scsi and vhost_vsock besides vhost_net.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815910
Title:
Apparmor blocks access to /dev/vhost-net
To manage notifications abo
Thanks Jamie for providing an approach that is a compromise between
upstreams needs and Ubuntu as a downstream - as well as at the same time
being a tradeoff between comfort and security.
I'll implement this as a downstream change in 19.10:
- add the comment to the config (thanks for writing it up
I've stated my preference for upstream: https://www.redhat.com/archives
/libvir-list/2019-April/msg00750.html
For Ubuntu, if the issue is causing a lot of issues, I'm open to a
distro patch that enables the access by default on the condition that
/etc/libvirt/qemu.conf is adjusted to have a commen
I tripped over this problem recently with an instance that needed its
neutron port recreated.
At some point the apparmor profile was regenerated while the instance
lacked a network interface and so the permission required to reattach it
was lost.
I ended up editing and reloading the profile manua
The same behavior is reproduced in case when VM was created with network
interface, interface detached, VM stopped (virsh destroy) and started
again without network. This usecase does not need OpenStack admin
privileges.
--
You received this bug notification because you are a member of Ubuntu
Bug
Nothing else came up in a while, I have forwarded the comments to the
mailing list and now wait for a consensus there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815910
Title:
Apparmor blocks ac
Thanks @Christian for continuing the discussion.
@James Page, I also use neutron ml2 ovs driver. I understand that in
default nova policy, only administrator can spawn instance without any
interface, but if someone else can "tune" the policy, he/she will have a
problem.
--
You received this bug
Yeah, thanks James that is just what I have assumed.
And the paused device is enough to have the rule added as expected.
@David and other reporters - can you provide a convincing case "due to
what" or "why" you are driving it the other way with no device at all
(initially)? As mentioned that is wh
This is not the default otherwise no ones cloud would actually work
right now.
Instances are created with a network interface in paused state - at
which point the interface plugging in neutron is executed; once that's
completed the instance transitions to running and boots.
That's the default beh
I chatted with David and got this when asking why this would be a common case.
cpaelzer: yep, it is the default setup of the latest version of
the nova-compute charm
That said, if this is the only reason then we might also juts change the charm.
But it clearly identifies that we want to pull
I am chiming in on behalf of our customer that is affected by this bug
and patched his AppArmor profile manually for the time being to solve
his issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/181
Thanks Jamie, that is exactly why I asked about it.
Here is a call to the bug reporter and other affected users that might watch
the bug.
Please chime in on the upstream discussion to clarify how "common it is to
start a VM with no network devices and then hotplug one".
Based on that will be th
FYI, I communicated my preference here: https://www.redhat.com/archives
/libvir-list/2019-March/msg00046.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815910
Title:
Apparmor blocks access to /
Unless the security Team really dislikes the idea of opening it up I'd
want to at least SRu this change to Bionic - further back I'm not so
sure (the further we go back the less hardening/fixes the interface will
have).
Adding bug tasks for that ...
** Also affects: libvirt (Ubuntu Cosmic)
Imp
FYI: https://www.redhat.com/archives/libvir-list/2019-February/msg00986.html
No feedback there yet
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815910
Title:
Apparmor blocks access to /dev/vhost-n
Thanks Christian.
So I will wait for merge your patch.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815910
Title:
Apparmor blocks access to /dev/vhost-net
To manage notifications about this bug g
As discussed I just send the patch and you can comment there :-)
So upstream for discussion now ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815910
Title:
Apparmor blocks access to /dev/vhost-
Use the full list as breakpoints yoou can easily get from source like
$ tail -n 60 src/security/security_apparmor.c | awk '/ = App/ {gsub(",","");
printf("b %s\n", $3);}'
But the only hit we get is the FD call as expected:
Thread 2 "libvirtd" hit Breakpoint 31, AppArmorSetFDLabel (mgr=0x7f6e3c00
@security - for the issue outlined above I'd like to suggest to add /dev
/vhost-net statically in src/security/apparmor/libvirt-qemu (and drop
the detection in virt-aa-helper as it is superfluous).
I'd want to have your input if you consider /dev/vhost-net safe enough
these days to do so?
--
You
Repro:
1. Starting a new guest from which I dropped any network (e.g. created via
uvtool)
2. Check the rendered profile - as expected there is no /dev/vhost-net
$ cat /etc/apparmor.d/libvirt/$(virsh dominfo disco-test-vhost | awk
'/^Security label:/ {print $3}').files
# DO NOT EDIT THIS FILE DIR
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: libvirt (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815910
Title:
Ap
Thanks Christian for replying.
Yes, I spawn instance without network interface and after a while I
would like to add it to the VM so it raises me an error.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bug
Hi Daniel,
thank you for your report and your help making Ubuntu better.
Your workaround is exactly the right way flag your system for your special
local configuration.
In later releases there is a file at:
/etc/apparmor.d/local/abstractions/libvirt-qemu
Which shall help to add a rule without c
30 matches
Mail list logo
