[PATCH] contrib/selinux: Enable mapping guest memory for libvirt guests

[PATCH] contrib/selinux: Enable mapping guest memory for libvirt guests

[Stefano Brivio]

This doesn't actually belong to passt's own policy: we should export
an interface and libvirt's policy should use it, because passt's
policy shouldn't be aware of svirt_image_t at all.

However, libvirt doesn't maintain its own policy, which makes policy
updates rather involved. Add this workaround to ensure --vhost-user
is working in combination with libvirt, as it might take ages before
we can get the proper rule in libvirt's policy.

Reported-by: Laine Stump <laine@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
---
 contrib/selinux/passt.te | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/contrib/selinux/passt.te b/contrib/selinux/passt.te
index 8e6120e..f595079 100644
--- a/contrib/selinux/passt.te
+++ b/contrib/selinux/passt.te
@@ -24,6 +24,12 @@ require {
 	type tmpfs_t;
 	type root_t;
 
+	# Workaround: passt --vhost-user needs to map guest memory, but
+	# libvirt doesn't maintain its own policy, which makes updates
+	# particularly complicated. To avoid breakage in the short term,
+	# deal with it in passt's own policy.
+	type svirt_image_t;
+
 	class file { ioctl getattr setattr create read write unlink open relabelto execute execute_no_trans map };
 	class dir { search write add_name remove_name mounton };
 	class chr_file { append read write open getattr ioctl };
@@ -131,3 +137,9 @@ allow passt_t user_tmp_t:dir { add_name write };
 allow passt_t user_tmp_t:file { create open };
 allow passt_t user_tmp_t:sock_file { create read write unlink };
 allow passt_t unconfined_t:unix_stream_socket { read write };
+
+# Workaround: passt --vhost-user needs to map guest memory, but
+# libvirt doesn't maintain its own policy, which makes updates
+# particularly complicated. To avoid breakage in the short term,
+# deal with it in passt's own policy.
+allow passt_t svirt_image_t:file { read write map };
-- 
@@ -24,6 +24,12 @@ require {
 	type tmpfs_t;
 	type root_t;
 
+	# Workaround: passt --vhost-user needs to map guest memory, but
+	# libvirt doesn't maintain its own policy, which makes updates
+	# particularly complicated. To avoid breakage in the short term,
+	# deal with it in passt's own policy.
+	type svirt_image_t;
+
 	class file { ioctl getattr setattr create read write unlink open relabelto execute execute_no_trans map };
 	class dir { search write add_name remove_name mounton };
 	class chr_file { append read write open getattr ioctl };
@@ -131,3 +137,9 @@ allow passt_t user_tmp_t:dir { add_name write };
 allow passt_t user_tmp_t:file { create open };
 allow passt_t user_tmp_t:sock_file { create read write unlink };
 allow passt_t unconfined_t:unix_stream_socket { read write };
+
+# Workaround: passt --vhost-user needs to map guest memory, but
+# libvirt doesn't maintain its own policy, which makes updates
+# particularly complicated. To avoid breakage in the short term,
+# deal with it in passt's own policy.
+allow passt_t svirt_image_t:file { read write map };
-- 
2.43.0

Re: [PATCH] contrib/selinux: Enable mapping guest memory for libvirt guests

[Andrea Bolognani]

On Thu, Feb 13, 2025 at 11:16:42PM +0100, Stefano Brivio wrote:
> This doesn't actually belong to passt's own policy: we should export
> an interface and libvirt's policy should use it, because passt's
> policy shouldn't be aware of svirt_image_t at all.
>
> However, libvirt doesn't maintain its own policy, which makes policy
> updates rather involved. Add this workaround to ensure --vhost-user
> is working in combination with libvirt, as it might take ages before
> we can get the proper rule in libvirt's policy.

Is the need to update libvirt's policy for these passt changes being
tracked anywhere? Because if not it will not take ages, it will
simply never happen. Especially if a workaround in passt's policy
effectively sweeps the issue under the rug.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [PATCH] contrib/selinux: Enable mapping guest memory for libvirt guests

[Stefano Brivio]

On Fri, 14 Feb 2025 05:30:44 -0800
Andrea Bolognani <abologna@redhat.com> wrote:

> On Thu, Feb 13, 2025 at 11:16:42PM +0100, Stefano Brivio wrote:
> > This doesn't actually belong to passt's own policy: we should export
> > an interface and libvirt's policy should use it, because passt's
> > policy shouldn't be aware of svirt_image_t at all.
> >
> > However, libvirt doesn't maintain its own policy, which makes policy
> > updates rather involved. Add this workaround to ensure --vhost-user
> > is working in combination with libvirt, as it might take ages before
> > we can get the proper rule in libvirt's policy.  
> 
> Is the need to update libvirt's policy for these passt changes being
> tracked anywhere?

No. :)

> Because if not it will not take ages, it will simply never happen.

It will happen. :)

> Especially if a workaround in passt's policy effectively sweeps the
> issue under the rug.

I'll take up the rug next week. :)

-- 
Stefano

Re: [PATCH] contrib/selinux: Enable mapping guest memory for libvirt guests

[Stefano Brivio]

On Fri, 14 Feb 2025 14:37:05 +0100
Stefano Brivio <sbrivio@redhat.com> wrote:

> On Fri, 14 Feb 2025 05:30:44 -0800
> Andrea Bolognani <abologna@redhat.com> wrote:
> 
> > On Thu, Feb 13, 2025 at 11:16:42PM +0100, Stefano Brivio wrote:  
> > > This doesn't actually belong to passt's own policy: we should export
> > > an interface and libvirt's policy should use it, because passt's
> > > policy shouldn't be aware of svirt_image_t at all.
> > >
> > > However, libvirt doesn't maintain its own policy, which makes policy
> > > updates rather involved. Add this workaround to ensure --vhost-user
> > > is working in combination with libvirt, as it might take ages before
> > > we can get the proper rule in libvirt's policy.    
> > 
> > Is the need to update libvirt's policy for these passt changes being
> > tracked anywhere?  
> 
> No. :)
> 
> > Because if not it will not take ages, it will simply never happen.  
> 
> It will happen. :)
> 
> > Especially if a workaround in passt's policy effectively sweeps the
> > issue under the rug.  
> 
> I'll take up the rug next week. :)

Tracked at https://github.com/fedora-selinux/selinux-policy/issues/2579.

-- 
Stefano