http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 Martin Kalivoda changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |supercoolemail@seznam.cz -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c2 --- Comment #2 from Martin Kalivoda --- (In reply to James Fehlig from comment #1)

Is apparmor running? E.g. what is the output of 'systemctl status apparmor.service' and 'aa-status'?

● apparmor.service - Load AppArmor profiles Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled) Active: active (exited) since Tue 2019-02-19 01:07:46 CET; 23h ago Main PID: 696 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) Memory: 0B CGroup: /system.slice/apparmor.service Feb 19 01:07:38 vhost4 systemd[1]: Starting Load AppArmor profiles... Feb 19 01:07:53 vhost4 apparmor.systemd[696]: Restarting AppArmor Feb 19 01:07:53 vhost4 apparmor.systemd[696]: Reloading AppArmor profiles Feb 19 01:07:53 vhost4 apparmor.systemd[696]: Skipped: /etc/apparmor.d/libvirt Feb 19 01:07:46 vhost4 systemd[1]: Started Load AppArmor profiles. ------------- apparmor module is loaded. 51 profiles are loaded. 50 profiles are in enforce mode. (omitted) 1 profiles are in complain mode. /usr/lib/systemd/system-generators/lvm2-activation-generator 8 processes have profiles defined. 8 processes are in enforce mode. (omitted) 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. No mentions of libvirt in any of the redacted parts -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c4 --- Comment #4 from Martin Kalivoda --- It should be noted, that this is quite worrying me for another reason: comments in /etc/libvirt/qemu.conf say that # SUSE Note: # Currently, Apparmor is the default security framework in SUSE # distros. If Apparmor is enabled on the host, libvirtd is # generously confined but users must opt-in to confine qemu # instances. Change this to a non-zero value to enable default # Apparmor confinement of qemu instances. However, changing the value of security_default_confined to 1 will NOT trigger the error and it will leave everything unconfined. Only reason why I got hit by this is because I am cautious about default and changed the security_driver explicitly. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c6 --- Comment #6 from James Fehlig --- (In reply to Martin Kalivoda from comment #3)

Well, there are of course libvirtd profiles (libvirtd, libvirtd//qemu_bridge_helper, virt-aa-helper), but not domain profiles (I have previously working profiles in /etc/apparmor.d/libvirt).

Domain profiles in /etc/apparmor.d/libvirt/ are generated when starting a VM and removed when shutting it down. -- You are receiving this mail because: You are on the CC list for the bug.

Domain profiles in /etc/apparmor.d/libvirt/ are generated when starting a VM and removed when shutting it down. This does not seems right, because https://gitlab.com/apparmor/apparmor/wikis/Libvirt#advanced-usage says, that If you need to adjust access controls for a single guest, adjust /etc/apparmor.d/libvirt-, where is the UUID of

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c8 --- Comment #8 from Martin Kalivoda --- (In reply to James Fehlig from comment #6) the guest Which would be totally useless if it would get removed at shutdown. It is also mentioned here https://doc.opensuse.org/documentation/leap/virtualization/html/book.virt/ch... Now, checking the source code and when this removal you mention was introduced: https://github.com/libvirt/libvirt/commit/eba2225bc52624e748cb875e10962bc4c4... and that it is included also in libvirt 4.0.0 which is in Leap 15 it seem that both documentations are wrong.

Since the libvirt apparmor driver is not loaded, the default security model is 'none'. Setting security_default_confined has no effect when the active model is a no-op. This is unfortuates, because comment makes it sound that this "if apparmor is available" applies only to libvirtd, but qemu instances "will be confined by default" when config is set to nonzero (as the condition does not seem to apply to this part as it is different sentence).

I just installed new Tumbleweed with KVM Host and Virtualization Tools pattern. I changed only security_driver, started libvirt and I get the same error. No other changes were made after installation. -- You are receiving this mail because: You are on the CC list for the bug.

why the libvirtd profile was not parsed. Libvirtd itself is confined and it's supporting utilities (libvirtd//qemu_bridge_helper, virt-aa-helper) are confined too, as stated in my comment #3 (which corrects #2 - it was poorly worded, because it was unclear whether libvirt means both libvirt-* profiled or also libvirtd - I meant just

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c10 --- Comment #10 from Martin Kalivoda --- (In reply to James Fehlig from comment #9) libvirt-*). To make it clear: - libvirtd is confined - apparmor works fine otherwise - failure in clean install can be triggered by explicitly setting security_driver to apparmor, nothing more is necessary.

I don't see any problems on my Tumbleweed KVM host Do you have updated Tumbleweed with libvirt 5 and did you explicitly set security_driver to apparmor in /etc/libvirt/qemu.conf ?

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c12 --- Comment #12 from Martin Kalivoda --- (In reply to James Fehlig from comment #11)

(In reply to Martin Kalivoda from comment #10) Old profiles in /etc/apparmor.d/libvirt were incorrect (unexpected tokens). I deleted them, but it didn't solve anything... which makes sense, since even clean install does not work for me. Apparently, just setting security_driver to apparmor is not enough to make it work but it used to be enough in near past. Should it still work? I just did anither install of Tumbleweed, this time into VM and I still get the error after setting security_driver to apparmor.

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c14 --- Comment #14 from Martin Kalivoda --- Unfortunately it fails between two lines, not meaningful info is there. In the meantime I have examined the source code. My problem comes from here https://github.com/libvirt/libvirt/blob/600462834f4ec1955a9a48a1b6b4a390b9c3... It calls probe on each item of array of externs: security_drivers. Probe of apparmor driver is called AppArmorSecurityManagerProbe: https://github.com/libvirt/libvirt/blob/d56afb8e3997ae19fd7449f773065a2b997d... It checks if TEMPLATE.qemu and TEMPLATE.lxc exist (both do as it does not print error). Before that it checks for use_apparmor(), since later checks were not even hit (they log errors and if they passed, then I wouldn't get my error), this must be the culprit. Now use_apparmor(): https://github.com/libvirt/libvirt/blob/d56afb8e3997ae19fd7449f773065a2b997d... First check (virResolveLink) is ok, because it does not print error. Next I dont' use lxc so no prolem here. Next it can probably access APPARMOR_PROFILES_PATH. Then it checks if libvirtd profile exists and is in enforcing mode by calling profile_status(libvirt_daemon, 1). Now profile_status(libvirt_daemon, 1): https://github.com/libvirt/libvirt/blob/d56afb8e3997ae19fd7449f773065a2b997d... Manually evaluating the code seems to be ok. String building should not fail, access to APPARMOR_PROFILES_PATH is ok, because it does not print error. The, libvirtd line is present and "(enforce)" is present next to it. So no problem here either. So I have started almighty strace and found that it passed readlink test, access test just to fail after https://github.com/libvirt/libvirt/blob/d56afb8e3997ae19fd7449f773065a2b997d... It must fail after that point, because it didn't log any error. Unfortunately, this would mean that strstr failed for some reason... I'll try to intercept c-library calls to check it out. Also, I don't see any way how it could possibly work for you :/ -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c16 --- Comment #16 from Martin Kalivoda --- C library functions were inlined by compiler... ltrace is of no use here. But at least I am sure it fails where I though because I have checked that it reads whole /sys/kernel/security/apparmor/profiles and fails right after that. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c18 --- Comment #18 from Martin Kalivoda --- (In reply to James Fehlig from comment #17) That must be it! It takes full path to libvirtd here https://github.com/libvirt/libvirt/blob/d56afb8e3997ae19fd7449f773065a2b997d... and then passes it to profile_status where profile list gets matched against it and matching fails, because profile list contains just profile name. One posiblity should be to remove this https://github.com/libvirt/libvirt/blob/d56afb8e3997ae19fd7449f773065a2b997d... and replace this https://github.com/libvirt/libvirt/blob/d56afb8e3997ae19fd7449f773065a2b997d... with rc = profile_status("libvirtd", 1); -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c20 --- Comment #20 from Martin Kalivoda --- Created attachment 798191 --> http://bugzilla.opensuse.org/attachment.cgi?id=798191&action=edit Audit log from clean VM where libvirtd failed due to this bug (In reply to Christian Boltz from comment #19) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c22 --- Comment #22 from Martin Kalivoda --- (In reply to Christian Boltz from comment #21) This has nothing to do with apparmor itself and I see no reason to expect denials in audit log. As described in #18: This bug is caused by wrong expectations from libvirt - it expects /usr/sbin/libvirtd in profile lists but profile list only contains "libvirtd" because profile was changed to named profile with name "libvirtd" by commit linked in #17. Code linked in #18 then thinks that libvirtd is not confined and thinks that apparmor is not activated which then results in error from original post. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1125841 http://bugzilla.opensuse.org/show_bug.cgi?id=1125841#c24 James Fehlig changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #24 from James Fehlig --- I sent a small patch series upstream to fix this issue and another one I encountered while testing VM confinement with the named libvirtd profile https://www.redhat.com/archives/libvir-list/2019-March/msg00053.html -- You are receiving this mail because: You are on the CC list for the bug.