On Thursday, 24 September 2020 14:53:25 CEST Richard W.M. Jones wrote:
On Thu, Sep 24, 2020 at 02:16:24PM +0200, Pino Toscano wrote:
On Thursday, 24 September 2020 13:53:57 CEST Richard W.M. Jones wrote:
Considering that /tmp is a general location for temporary files, it's common that files may end with a tmp_t-alike label when moved back to the destination place (e.g. after a rename()). That is not the only situation like this that I saw in the past.
In permissive mode, all these situation are logged in the audit log, yes, but they cause no blocks nor errors.
It's also fine for an administrator to switch a system to permissive and then back to enforcing without relabelling or rebooting.
A mislabelled /etc/passwd is still read and used fine in permissive mode. Switch back from permissive to enforcing without a relabelling is generally not a good idea, especially after the system ran for a lot of time after the switch to permissive.
It's seems true from what you wrote above that someone could copy /tmp/passwd -> /etc/passwd and it would have a wrong label. But virt-v2v could fix that label, which even in permissive mode sounds like a win.
The question is: why? If the system had wrong labels even for system files, and the administrator did not bother/want to fix them (because of permissive), why should virt-v2v? Even if virt-v2v relabels a permissive guest, the labels will get out of sync once the guest runs again and does its own stuff, so there is no gain here.
I don't think this part is true (except in rather contrived situations).
I asked few questions, so "don't think it is true" does not seem correct to me.
It seems as if when setting the mode to Permissive when the guest is running normally, it *is* attempting to maintain the correct labels.
There is a difference between "attempting" and "succeeding". Permissive does some effort, but there is *zero* guarantee that the labels of the system are correct. And again: setting a Fedora/RHEL/CentOS system as anything different than enforcing requires an explicit action (either in /etc/selinux/config, or at runtime with `setenforce`, or when installing via kickstart, etc), so this is a situation that was explicitly requested.
So virt-v2v should do the same thing.
Right: respect the administrator choice to not enforce the SELinux policy on filesystems in any way. -- Pino Toscano