Re: [Libguestfs] [v2v PATCH 4/4] convert_linux: install the QEMU guest agent with a firstboot script
On 06/07/22 17:22, Richard W.M. Jones wrote:
On Tue, Jun 07, 2022 at 01:59:30PM +0100, Richard W.M. Jones wrote:
> On Mon, Jun 06, 2022 at 04:19:41PM +0200, Laszlo Ersek wrote:
>> + (* Disable SELinux temporarily around package installation. Refer
to
>> + * <https://bugzilla.redhat.com/show_bug.cgi?id=2028764#c7>
and
>> + * <https://bugzilla.redhat.com/show_bug.cgi?id=2028764#c8>;.
>> + *)
>> + fbs "setenforce 0"
>> + (sprintf "#!/bin/sh\n\
>> + rm -f %s\n\
>> + if command -v getenforce >/dev/null &&\n\
>> + \ \ test Enforcing = \"$(getenforce)\"\n\
>> + then\n\
>> + \ \ touch %s\n\
>> + \ \ setenforce 0\n\
>> + fi\n" selinux_enforcing selinux_enforcing);
>> + fbs "install qga" inst_cmd;
>> + fbs "setenforce restore"
>> + (sprintf "#!/bin/sh\n\
>> + if test -f %s; then\n\
>> + \ \ setenforce 1\n\
>> + \ \ rm -f %s\n\
>> + fi\n" selinux_enforcing selinux_enforcing);
>
> Sounds horrible! But if that's what is needed ...
OK, now I caught up with the BZ comments, it really seems odd to me
that a service or script can run dnf, but that dnf doesn't transition
to the right SELinux context in order to do its work, but also dnf
doesn't fail immediately ("error: wrong context!") either.
I've checked the fedora / selinux-policy.git contents; unfortunately
most of the syntax is non-intuitive for me. I gathered that most
system-level virt executables are labeled virtd_exec_t, including our
own "firstboot.sh", but the same applies to the various libvirt daemons.
Once they run, they somehow "decay" or get converted to "virtd_t",
and
that class (?) does not have the permission to transition to
"rpm_script_t". It's like DNF just inherits the parent context, and when
that context is a "root shell" (for example), then "rpm_script_t" can
be
transitioned to.
Granting "rpm_script_t" globally to virtd_t would not be right (I doubt
we want libvirt daemons to run RPM scripts), but do we really want
"firstboot.sh" to have its own classification in the policy? And even
so, it will not help with *existing*, installed guests, whose installed
SELinux policies will not know about any such update. That's why I
ultimately decided to just turn off SELinux temporarily: I see no way to
retroactively convince installed (and converted) guests to grant
additional *nuanced* permissions to "firstboot.sh". (We could forcibly
run an --upgrade for the SELinux policy package, but what about old
distros for which no updates will ever be released again?)
This would not be a problem with installing qga immediately from the
appliance (which does not use SELinux), but you explained why we prefer
not to depend on network access during conversion; I don't want to
challenge that.
However I don't know enough about SELinux to really understand whether
this is how it's supposed to work or not.
In reply to your other comment about --firstboot-install, it is
possible that this did work but has seen been broken by some change.
I don't believe we test it thoroughly anywhere.
I think I'd like to stick with this kludge for now.
Thanks
Laszlo