QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.

Hi Sergio,
Although release + is already added, but the process still didn't move forward, I guess we still need to do it manually:(.

Regards,
Xiaoling

Hi Sergio and Vivek,
I'm verifying this bug, as it's a new feature for virtiofs, I listed two test scenarios, but I'm not sure part of results are correct.
Could you help to check? Thanks in advance.


Test with the following pkgs:
virtiofsd-1.4.0-1.el9.x86_64
5.14.0-138.el9.x86_64(guest && host kernel)
qemu-kvm-7.0.0-9.el9.x86_64

--------------------Test scenario 1---------------------

Disable selinux on host and start selinux on guest.
1. Start virtiofsd without security-label support.
# /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1 
[root@bootp-73-114-209 mm]# touch {a,b}
[root@bootp-73-114-209 mm]# ll -Z
total 8
-rw-r--r--. 1 root root system_u:object_r:virtiofs_t:s0 4 Aug  4 15:06 a
-rw-r--r--. 1 root root system_u:object_r:virtiofs_t:s0 4 Aug  4 15:06 b
# getfattr -m '' /mnt/mm/a
getfattr: /mnt/mm/a: Operation not supported
-------------------->>There is no selinux support on shared dir inside guest, and security contest is 'virtiofs_t' .

2. Start virtiofs with xattr.
# /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1 --xattr
[root@bootp-73-114-209 mm]# touch {a,b}
[root@bootp-73-114-209 mm]# ll -Z
total 8
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 4 Aug  4 15:15 a
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 4 Aug  4 15:15 b
[root@localhost mm]# getfattr -m '' a
[root@localhost mm]# 
---------------------->> the security context is 'unlabeled_t', is that right??

3. Start virtiofsd with security-label support.
# /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1 --security-label --xattr
[root@bootp-73-114-209 mm]# touch {a,b}
[root@bootp-73-114-209 mm]# ll -Z
total 0
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 15:29 a
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 15:29 b
[root@bootp-73-114-209 mm]# getfattr -m '' a
# file: a
security.selinux
---------------------->> can set sel=curity.selinux attribute to files in shared dir, and security context is set to 'user_home_t', I think it is expected.

Check from host side, the file created inside guest can get security.selinux attribute.
[root@dell-per440-20 test]# getfattr -m '' a
# file: a
security.selinux

--------------------Test scenario 2---------------------
Enable selinux on host and guest.
1. Start virtiofsd with xattr remapping.
# /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1 --xattr --security-label -o xattrmap=:map:security.selinux:trusted.virtiofsd.: --modcaps=+sys_admin

2. Create a new file on shared dir inside guest.
(guest)# touch a
(guest)# ll -Z
total 0
-rw-r--r--. 1 root root unconfined_u:object_r:unlabeled_t:s0 0 Aug  4 17:47 a
(guest)# getfattr -m '' a
# file: a
security.selinux
----------------------------------->>Is the security context right, I thought it should be 'user_home_t'.
(host)# ll -Z
total 0
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 05:47 a
(host)# getfattr -m '' a
# file: a
security.selinux
trusted.virtiofsd.security.selinux

2. Create a new file on shared guest inside host.
(host)# touch b
(host)# ll -Z
total 0
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 05:49 b
(host)# 
(host)# getfattr -m '' b
# file: b
security.selinux

(guest)# ll -Z
total 0
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0     0 Aug  4 17:49 b
(guest)# getfattr -m '' b
b: Input/output error
--------------------------------->> Is the error info expected?


(host)# setfattr -n trusted.virtiofsd.security.selinux b
(host)# getfattr -m '' b
# file: b
security.selinux
trusted.virtiofsd.security.selinux

(guest)#  getfattr -m '' b
# file: b
security.selinux

Best Regards,
Xiaoling

(In reply to xiagao from comment #11)
> Hi Sergio and Vivek,
> I'm verifying this bug, as it's a new feature for virtiofs, I listed two
> test scenarios, but I'm not sure part of results are correct.
> Could you help to check? Thanks in advance.
> 

I think our primary use case is to have SELinux enabled in guest as well
as on host. So let us focus more on that.

For the sake of more testing, we could think of covering the use case where SELinux is disabled on
host but enabled on guest. But I am not too particular about it yet because I am not aware who
is going to use this configuration.

Also, can you please use the instructions mentioned here. These instructions as users to provide
CAP_SYS_ADMIN as well as use xattr remapping.

https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/README.md#selinux-support

> 
> Test with the following pkgs:
> virtiofsd-1.4.0-1.el9.x86_64
> 5.14.0-138.el9.x86_64(guest && host kernel)
> qemu-kvm-7.0.0-9.el9.x86_64
> 
> --------------------Test scenario 1---------------------
> 
> Disable selinux on host and start selinux on guest.

If you are disabling SELinux on host, you will need to boot host kernel
with selinux=0 kernel command line option.


> 1. Start virtiofsd without security-label support.
> # /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1 

You seem to be testing that virtiofsd does not support xattr/SELinux instead.
I think in this case virtiofs mount point falls back to some default
label for the whole filesystem (virtiofs_t).

> [root@bootp-73-114-209 mm]# touch {a,b}
> [root@bootp-73-114-209 mm]# ll -Z
> total 8
> -rw-r--r--. 1 root root system_u:object_r:virtiofs_t:s0 4 Aug  4 15:06 a
> -rw-r--r--. 1 root root system_u:object_r:virtiofs_t:s0 4 Aug  4 15:06 b
> # getfattr -m '' /mnt/mm/a
> getfattr: /mnt/mm/a: Operation not supported
> -------------------->>There is no selinux support on shared dir inside
> guest, and security contest is 'virtiofs_t' .

This seems right because virtiofsd does not have "xattr" support.

> 
> 2. Start virtiofs with xattr.
> # /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1
> --xattr
> [root@bootp-73-114-209 mm]# touch {a,b}
> [root@bootp-73-114-209 mm]# ll -Z
> total 8
> -rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 4 Aug  4 15:15 a
> -rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 4 Aug  4 15:15 b
> [root@localhost mm]# getfattr -m '' a
> [root@localhost mm]# 
> ---------------------->> the security context is 'unlabeled_t', is that
> right??
> 
> 3. Start virtiofsd with security-label support.
> # /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1
> --security-label --xattr

You need to use xattr remapping as well as give cap_sys_admin as described in the documentation.


> [root@bootp-73-114-209 mm]# touch {a,b}
> [root@bootp-73-114-209 mm]# ll -Z
> total 0
> -rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 15:29 a
> -rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 15:29 b
> [root@bootp-73-114-209 mm]# getfattr -m '' a
> # file: a
> security.selinux
> ---------------------->> can set sel=curity.selinux attribute to files in
> shared dir, and security context is set to 'user_home_t', I think it is
> expected.
> 
> Check from host side, the file created inside guest can get security.selinux
> attribute.
> [root@dell-per440-20 test]# getfattr -m '' a
> # file: a
> security.selinux
> 
> --------------------Test scenario 2---------------------
> Enable selinux on host and guest.
> 1. Start virtiofsd with xattr remapping.
> # /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1
> --xattr --security-label -o
> xattrmap=:map:security.selinux:trusted.virtiofsd.: --modcaps=+sys_admin

This test scenario looks good. This should be the focus of testing first.

> 
> 2. Create a new file on shared dir inside guest.
> (guest)# touch a
> (guest)# ll -Z
> total 0
> -rw-r--r--. 1 root root unconfined_u:object_r:unlabeled_t:s0 0 Aug  4 17:47 a
> (guest)# getfattr -m '' a
> # file: a
> security.selinux
> ----------------------------------->>Is the security context right, I
> thought it should be 'user_home_t'.

You are only querying name of xattr and not its value. Use "getfattr -d -m - a" instead.

In my case of a fedora VM, I see virtiofs mount point getting label "mnt_t". And when 
I created file under it, that file got label as "mnt_t" as well. That kind of sounds
right. Selinux-testsuite I mentioned i think checks all these things already.

> (host)# ll -Z
> total 0
> -rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 05:47 a
> (host)# getfattr -m '' a
> # file: a
> security.selinux
> trusted.virtiofsd.security.selinux

With xattr mapping, guest and host selinux attrs are stored in separate xattrs. Host's
SELinux attribute is stored in security.selinux xattr while guest's selinux attr is
stored in "trusted.virtiofsd.security.selinux" xattr.

> 
> 2. Create a new file on shared guest inside host.
> (host)# touch b
> (host)# ll -Z
> total 0
> -rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 05:49 b
> (host)# 
> (host)# getfattr -m '' b
> # file: b
> security.selinux
> 
> (guest)# ll -Z
> total 0
> -rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0     0 Aug  4 17:49 b
> (guest)# getfattr -m '' b
> b: Input/output error
> --------------------------------->> Is the error info expected?
>

This is not expected. I was debugging this and I think there is an issue
with rust virtiofsd. I have opened an issue upstream with some explanation.
This needs to be fixed. If you like you can open a separate bug to keep
track of this. This only happens if you create file on host directly
and then access it from guest with SELinux support enabled.

https://gitlab.com/virtio-fs/virtiofsd/-/issues/55

(In reply to Vivek Goyal from comment #16)
> (In reply to xiagao from comment #11)
> > Hi Sergio and Vivek,
> > I'm verifying this bug, as it's a new feature for virtiofs, I listed two
> > test scenarios, but I'm not sure part of results are correct.
> > Could you help to check? Thanks in advance.
> > 
> 
> I think our primary use case is to have SELinux enabled in guest as well
> as on host. So let us focus more on that.
> 
> For the sake of more testing, we could think of covering the use case where
> SELinux is disabled on
> host but enabled on guest. But I am not too particular about it yet because
> I am not aware who
> is going to use this configuration.
> 
> Also, can you please use the instructions mentioned here. These instructions
> as users to provide
> CAP_SYS_ADMIN as well as use xattr remapping.
> 
> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/README.md#selinux-support
> 
> > 
> > Test with the following pkgs:
> > virtiofsd-1.4.0-1.el9.x86_64
> > 5.14.0-138.el9.x86_64(guest && host kernel)
> > qemu-kvm-7.0.0-9.el9.x86_64
> > 
> > --------------------Test scenario 1---------------------
> > 
> > Disable selinux on host and start selinux on guest.
> 
> If you are disabling SELinux on host, you will need to boot host kernel
> with selinux=0 kernel command line option.
> 
> 
> > 1. Start virtiofsd without security-label support.
> > # /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1 
> 
> You seem to be testing that virtiofsd does not support xattr/SELinux instead.
> I think in this case virtiofs mount point falls back to some default
> label for the whole filesystem (virtiofs_t).
> 
> > [root@bootp-73-114-209 mm]# touch {a,b}
> > [root@bootp-73-114-209 mm]# ll -Z
> > total 8
> > -rw-r--r--. 1 root root system_u:object_r:virtiofs_t:s0 4 Aug  4 15:06 a
> > -rw-r--r--. 1 root root system_u:object_r:virtiofs_t:s0 4 Aug  4 15:06 b
> > # getfattr -m '' /mnt/mm/a
> > getfattr: /mnt/mm/a: Operation not supported
> > -------------------->>There is no selinux support on shared dir inside
> > guest, and security contest is 'virtiofs_t' .
> 
> This seems right because virtiofsd does not have "xattr" support.
> 
> > 
> > 2. Start virtiofs with xattr.
> > # /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1
> > --xattr
> > [root@bootp-73-114-209 mm]# touch {a,b}
> > [root@bootp-73-114-209 mm]# ll -Z
> > total 8
> > -rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 4 Aug  4 15:15 a
> > -rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 4 Aug  4 15:15 b
> > [root@localhost mm]# getfattr -m '' a
> > [root@localhost mm]# 
> > ---------------------->> the security context is 'unlabeled_t', is that
> > right??
> > 
> > 3. Start virtiofsd with security-label support.
> > # /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1
> > --security-label --xattr
> 
> You need to use xattr remapping as well as give cap_sys_admin as described
> in the documentation.
> 
> 
> > [root@bootp-73-114-209 mm]# touch {a,b}
> > [root@bootp-73-114-209 mm]# ll -Z
> > total 0
> > -rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 15:29 a
> > -rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 15:29 b
> > [root@bootp-73-114-209 mm]# getfattr -m '' a
> > # file: a
> > security.selinux
> > ---------------------->> can set sel=curity.selinux attribute to files in
> > shared dir, and security context is set to 'user_home_t', I think it is
> > expected.
> > 
> > Check from host side, the file created inside guest can get security.selinux
> > attribute.
> > [root@dell-per440-20 test]# getfattr -m '' a
> > # file: a
> > security.selinux
> > 
> > --------------------Test scenario 2---------------------
> > Enable selinux on host and guest.
> > 1. Start virtiofsd with xattr remapping.
> > # /usr/libexec/virtiofsd -o source=/home/test  --socket-path=/tmp/sock1
> > --xattr --security-label -o
> > xattrmap=:map:security.selinux:trusted.virtiofsd.: --modcaps=+sys_admin
> 
> This test scenario looks good. This should be the focus of testing first.
> 
> > 
> > 2. Create a new file on shared dir inside guest.
> > (guest)# touch a
> > (guest)# ll -Z
> > total 0
> > -rw-r--r--. 1 root root unconfined_u:object_r:unlabeled_t:s0 0 Aug  4 17:47 a
> > (guest)# getfattr -m '' a
> > # file: a
> > security.selinux
> > ----------------------------------->>Is the security context right, I
> > thought it should be 'user_home_t'.
> 
> You are only querying name of xattr and not its value. Use "getfattr -d -m -
> a" instead.
> 
> In my case of a fedora VM, I see virtiofs mount point getting label "mnt_t".
> And when 
> I created file under it, that file got label as "mnt_t" as well. That kind
> of sounds
> right. Selinux-testsuite I mentioned i think checks all these things already.
> 
> > (host)# ll -Z
> > total 0
> > -rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 05:47 a
> > (host)# getfattr -m '' a
> > # file: a
> > security.selinux
> > trusted.virtiofsd.security.selinux
> 
> With xattr mapping, guest and host selinux attrs are stored in separate
> xattrs. Host's
> SELinux attribute is stored in security.selinux xattr while guest's selinux
> attr is
> stored in "trusted.virtiofsd.security.selinux" xattr.
> 
> > 
> > 2. Create a new file on shared guest inside host.
> > (host)# touch b
> > (host)# ll -Z
> > total 0
> > -rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Aug  4 05:49 b
> > (host)# 
> > (host)# getfattr -m '' b
> > # file: b
> > security.selinux
> > 
> > (guest)# ll -Z
> > total 0
> > -rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0     0 Aug  4 17:49 b
> > (guest)# getfattr -m '' b
> > b: Input/output error
> > --------------------------------->> Is the error info expected?
> >
> 
> This is not expected. I was debugging this and I think there is an issue
> with rust virtiofsd. I have opened an issue upstream with some explanation.
> This needs to be fixed. If you like you can open a separate bug to keep
> track of this. This only happens if you create file on host directly
> and then access it from guest with SELinux support enabled.
> 
> https://gitlab.com/virtio-fs/virtiofsd/-/issues/55

OK. Vivek.
-  We'll focus more on SELinux enabled in guest as well as on host.
-  Use "getfattr -d -m - a" instead of 'getfattr -m  a' and 'll -Z a'.
-  As my understanding the primary function works, and I have filed a new bz 2121972(aligned with your upstream issue)for the minor issue.
-  For the part of test cases failed in selinux-testsuit, I would like to report another bz to track if they are not tool/env issue.

And I suppose to set Verified status to this bz, if you have any concern, feel free to change it back.

Regards,
Xiaoling
Thanks,
Xiaoling

(In reply to xiagao from comment #19)

> -  For the part of test cases failed in selinux-testsuit, I would like to
> report another bz to track if they are not tool/env issue.

Hi Xaioling,

Have you opened another bz to keep track of issue why selinux-testsuite is not passing for you. For me it seems
to work.

Lets open a bug and keep track of it. Its important to make sure it works for you so that you can continue
to test it in future releases and if something regresses, catch it.

Also I have asked few questions. Please have a look.

host kernel: kernel-5.14.0-146.el9.x86_64
guest kernel: kernel-5.14.0-145.el9.x86_64
virtiofsd-1.4.0-1.el9.x86_64

(host)# getenforce
Permissive
(guest)# getenforce
Permissive

(In reply to Vivek Goyal from comment #22)
> (In reply to xiagao from comment #19)
> 
> > -  For the part of test cases failed in selinux-testsuit, I would like to
> > report another bz to track if they are not tool/env issue.
> 
> Hi Xaioling,
> 
> Have you opened another bz to keep track of issue why selinux-testsuite is
> not passing for you. For me it seems
> to work.
> 
> Lets open a bug and keep track of it. Its important to make sure it works
> for you so that you can continue
> to test it in future releases and if something regresses, catch it.
> 
> Also I have asked few questions. Please have a look.

Hello Vivek, I clone a new bz123220,we can talk selinux-testsuit issue in that.

BR,
Xiaoling

(In reply to xiagao from comment #27)

> Hello Vivek, I clone a new bz123220,we can talk selinux-testsuit issue in
> that.
> 

Above bug seems to be about "ftp" and not selinux-testsuite.

Just clearing the needinfo as it seem addressed now.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virtiofsd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8166