Re: Apparmor (and other) Issues

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 07 Feb 2025 06:49:45 +0000
Prafulla Giri <prafulla.giri@protonmail.com> wrote:

> On Wednesday, February 5th, 2025 at 4:01 PM, Stefano Brivio
> <sbrivio@redhat.com> wrote:
> 
> > But the libvirt profile is not associated to the
> > process, oops.  
> 
> Oh, so this is what is being worked upon: that Apparmor is not making
> the association

That, I'm not sure, but at least Andrea asked openSUSE and Ubuntu
people for comments. I just prepared (and merged) a workaround for the
moment. You are Cc'ed on the patch. If you want to test it, you should
add this:

  # Workaround: libvirt's profile comes with a passt subprofile which includes,
  # in turn, <abstractions/passt>, and adds libvirt-specific rules on top, to
  # allow passt (when started by libvirtd) to write socket and PID files in the
  # location requested by libvirtd itself, and to execute passt itself.
  #
  # However, when libvirt runs as unprivileged user, the mechanism based on
  # virt-aa-helper, designed to build per-VM profiles as guests are started,
  # doesn't work. The helper needs to create and load profiles on the fly, which
  # can't be done by unprivileged users, of course.
  #
  # As a result, libvirtd runs unconfined if guests are started by unprivileged
  # users, starting passt unconfined as well, which means that passt runs under
  # its own stand-alone profile (this one), which implies in turn that execve()
  # of /usr/bin/passt is not allowed, and socket and PID files can't be written.
  #
  # Duplicate libvirt-specific rules here as long as this is not solved in
  # libvirt's profile itself.
  /usr/bin/passt r,
  owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw,
  owner @{run}/libvirt/qemu/passt/* rw,

to your /etc/apparmor.d/usr.bin.passt. Note that changes to AppArmor
policy files are retained as configuration, so, if you edit it, package
upgrades won't override things automatically. You will need to:

  apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall passt

> whereas SELinux is doing it's thing as it's supposed to.

Right, that's because SELinux can do this:

  https://selinuxproject.org/page/MultiCategorySecurity

with AppArmor, it needs to be "emulated", somehow.

> > We're just trying to make things as
> > strict as possible, and depending on specific paths.  
> 
> I see. I'm glad this approach of as-strict-as-possible is being taken.
> 
> > We'll probably need to make them a bit looser for the moment being
> > and perhaps just allow passt, no matter who starts it, to write to
> > /var/run/**.  
> 
> I believe user-mode virtual machines only need access to
> /run/user/$USER and not /var/run. Not even /run/*, but only
> /run/user/$USER. So if that work-around is to be implemented, that
> would be the strictest version of it: each user-started passt process
> gets access to $XDG_RUNTIME_DIR of it's owner (and not outside of it).

It depends, because if you start passt as root, socket and PID go to
@{run}/libvirt/qemu/passt/*, and if you don't, the location becomes
@{run}/user/[0-9]*/libvirt/qemu/run/passt/*.

@{run} is an AppArmor handle for /var/run and /run, I think (aren't
they generally linked anyway?). Note that Ubuntu and openSUSE might
use slightly different paths.

> It also seems that more and more of us use $XDG_RUNTIME_DIR in lieu
> of /tmp in our personal shell scripts, because it kinda' feels like a
> more private /tmp.

Yeah, it is.

> Also, the `passt` update fixing DNS issue hasn't yet made it to
> Debian Trixie, yet.

I didn't release the fix yet. I merged it (upstream), but actually I
was expecting you would give it a quick try. If I'm more confident
about the change, I can do things faster.

> I figure it's going to take some time (?) Perhaps
> I should venture to Debian Sid, myself.

It's not in Debian Sid either because I didn't make a new release of
passt, yet.

It probably makes sense to make one next week (we release quite often,
especially if there's one or more fixes that might be important for
somebody, such as this one). As Debian maintainer I also update Debian
packages within a couple of hours.

Sid to testing is usually five days of difference, look:

  https://tracker.debian.org/pkg/passt/news/

-- 
Stefano