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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
