search

cockpit-project / cockpit-machines

Cockpit UI for virtual machines
GNU Lesser General Public License v2.1
297 stars 75 forks source link

AppArmor permission issues on Debian #1865

Open garrett opened 1 month ago

garrett commented 1 month ago

I had a seperate SSD that I wanted to dedicate to the VM. AppArmor blocks access to anything that isn't in the default libvirt image directory and it isn't made clear how to configure a data pool on a different drive to be whitelisted, and I ended up having to disable the relevant security feature as that what people with the same issues ended up doing - there didn't seem to be anything in documentation about this

Originally posted by @Betonhaus in https://github.com/cockpit-project/cockpit-machines/issues/680#issuecomment-2415891714

garrett commented 1 month ago

I'm not sure if we can directly fix this, but we might be able to add a hint about the issue and a way to resolve it otherwise.

Betonhaus commented 1 month ago

I'm not sure if we can directly fix this, but we might be able to add a hint about the issue and a way to resolve it otherwise.

A clarified error message would help. I spent too much time fussing with chown and switching between system and user mode before I found a hint to the actual issue

jelly commented 1 month ago

This feels more like an Ubuntu bug, where it should create the relevant policy when creating a new storage pool (it afaik already generates them for virtual machines).

Getting a "good" error message would involve scraping dmesg or journalctl for apparmor=DENIED:

We already work around in our tests for this issue:

test/check-machines-disks:        # AppArmor doesn't like the non-standard path for our storage pools
test/check-machines-disks:            self.allow_journal_messages(f'.* type=1400 .* apparmor="DENIED" operation="open" profile="libvirt.* name="{self.vm_tmpdir}.*')  # noqa: E501

For which there are existing bug reports:

https://stackoverflow.com/questions/63767647/virt-aa-helper-doesnt-add-path-for-storage-pool-in-apparmor-generated-rules links to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398 links to: https://gitlab.com/libvirt/libvirt/-/issues/135

jelly commented 1 month ago

Looking at our tests further, we only do this on debian-testing so this should work out of the box on Ubuntu and older Debian versions. But we do have an exception for block devics:

        # Apparmor on debian and ubuntu may prevent access to /dev/sdb1 when starting VM,
        # https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398
garrett commented 2 weeks ago

So having a better message would be great; here's a start, which lifts from the above.

Note that this is just a rough draft, showing that we should have a title, description that explains the problem and provides some kind of suggestion of what to do, and probably a link to the issue on a site+bug that's not going away anytime soon. (Launchpad and/or libvirt on GitLab are both probably fine.) This is meant as a starting point as to what the issue should probably be like. Feel free to even throw it all away and suggest something better, if you have a strong opinion on what to do.

AppArmor may prevent access to $DISK

AppArmor on $AFFECTED_HOST_OS may prevent access to $DISK when starting VM. Either use "block" formatted disks or add access to AppArmor.

Upstream issue: <a href="https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398>launchpad:1677398</a>

(The launchpad link should have the external icon and should actually be a link, instead of some raw HTML text.)

I guess we could use an expandable inline alert. If we do have links, they should be inside the description (so they're not visible by default, only when expanding). There are probably two places where we could show this: Either at the top at the top of the storage. It would be possible to have some kind of error message in the contextual menu, but the bug is blocking all the storage (not necessarily individual disks), so it makes sense to have it in one place, I think.