microcloud snap-: apparmor denial while reading ssl certificate
Closed this issue · 13 comments
I have been playing with microcloud setup for a while now.
I have three arm64 boards all with ubuntu core 22 images
2 Xilinx KV260 and a Mediatek board.
While the setup works fine . But even under working microcloud setup, I see following apparmor denial message
`
729:[ 1062.382278] audit: type=1400 audit(1700484339.402:206): apparmor="DENIED" operation="open" profile="snap.microcloud.microcloud" name="/var/lib/snapd/hostfs/etc/ssl/certs/ca-certificates.crt" pid=5344 comm="microcloud" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
`
Even with above error , I am able to launch lxd containers over microcloud and run workloads. I don't know whether this will affect any other use case under microcloud.
For the versions of the snaps that I am using....
`
lxd 5.19-31ff7b6 26096 latest/stable canonical** -
microceph 0+git.7b5672b 710 quincy/stable canonical** -
microcloud 1.1-04a1c49 737 latest/stable canonical** -
microovn 22.03.3+snap2d1a04de44 301 22.03/stable canonical** -
`
https://forum.snapcraft.io/t/custom-certificate-support/28168 suggest this should just work. @masnax I know we do some special handling around that in lxd-pkg-snap, do you think we need to do the same in microcloud-pkg-snap?
@simondeziel What is LXD's special handling around this? I've seen this error creep up a few times here and there so if there's something we can do about it I think we should.
Hmm so this is based on LXD having its own internal /etc. I think that might be a bit overkill for MicroCloud at this point. I'll see what the snapd people have to say about this.
FWIW this seems to happen when MicroCloud reaches out to each remote LXD prior to clustering to fetch the available disks on the systems.
Does microcloud need to access the system certs at all? Perhaps we should be configuring go not to use them?
Does microcloud need to access the system certs at all? Perhaps we should be configuring go not to use them?
This is happening in ConnectLXD when setting up TLS. If ConnectionArgs.TLSCA is unset, then LXD will use the system config:
https://github.com/canonical/lxd/blob/f86e64427c65fd1d5061f9c45700f3618710e7d7/shared/network.go#L74-L79
So we could add some flag to ConnectionArgs to make it not set anything in this case.
Considering that LXD clusters can use certs from official root CAs (like Let's Encrypt and such) maybe we should keep the system certs?
Actually, looking at LXD's configuration, it seems to be reading the certs directly from /var/lib/snapd/hostfs/etc/ssl, but according to the link @simondeziel posted, it should just be able to access /etc/ssl directly, so maybe that's what we need here.
Indeed I'm not getting the error if I change LXD to read from /etc/ssl directly.
Should be fixed by canonical/lxd#12541 once it's merged and MicroCloud is updated.
@masnax even though it's a LXD issue I would keep it here for tracking purposes and we can close it after MicroCloud got updated?