similar to: virt-builder & virt-sysprep: Avoiding SELinux relabelling

On Tue, 21 Jan 2014, Richard W.M. Jones wrote: > A common problem that people have with virt-builder and virt-sysprep > is which guests that use SELinux, like Fedora and RHEL. In both cases > we touch /.autorelabel in the guest, which means the guest has to > reboot once during its first boot. ... snip much analysis ... > (4) It can touch '/.autorelabel' which causes an

This implements the --selinux-relabel option for virt-customize, virt-builder and virt-sysprep. There is no need to autorelabel functionality now. Thanks: Stephen Smalley --- builder/Makefile.am | 1 + builder/virt-builder.pod | 20 +++++++++---------- customize/Makefile.am | 2 ++ customize/SELinux_relabel.ml | 46 +++++++++++++++++++++++++++++++++++++++++++

On Tue, Jan 21, 2014 at 12:01:45PM -0500, R P Herrold wrote: > (5) it can do an additional step at very end of the post > install: > restorecon -R / This doesn't work on its own. I suspect this would work: load_policy && restorecon -R / except it gives an error for me: SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.29, searching for

[ I realized that we were discussing adding this feature, in various private email, IRC, and this long bugzilla thread: https://bugzilla.redhat.com/show_bug.cgi?id=1060423 That's not how we should do things. Let's discuss it on the mailing list. ] One thing that virt-customize/virt-sysprep/virt-builder have to do is relabel SELinux guests. What we do at the moment

Do SELinux relabelling properly.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1212807

On Tue, 21 Jan 2014, Richard W.M. Jones wrote: > This could be because the kernel of the libguestfs appliance doesn't > match the kernel of the guest. We also encounter such problems when re-labelling images not matching the dom0 kernel distribution, and just accept the relabel delay (slow and linear) and second boot (boots are fast) -- but I had hoped you had a solution ;) -- Russ

We just remove the process accounting files previously without touch a empty file, this will cause psacct runs error. Restart the service can't help us create this file auto. couldn't open file '/var/account/pacct': No such file or directory Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- po/POTFILES-ml | 1 + sysprep/Makefile.am

v1 -> v2: - Add simple test of the setfiles API. - Use SELinux_relabel module in virt-v2v (instead of touch /.autorelabel). - Small fixes. Rich.

On Wed, Sep 23, 2020 at 05:57:50PM +0200, Pino Toscano wrote: > Do not attempt to relabel a guest in case its SELinux enforcing mode is > not "enforcing", as it is either pointless, or it may fail because of an > invalid policy configured. > --- > mlcustomize/SELinux_relabel.ml | 26 +++++++++++++++++++++++++- > 1 file changed, 25 insertions(+), 1 deletion(-) >

We can use the setfiles(8) command to relabel the guest filesystem, even though we don't have a policy loaded nor SELinux enabled in the appliance kernel. This also deprecates or removes the old and broken SELinux support. This patch isn't quite complete - I would like to add some tests to the new API. I'm posting here to garner early feedback. Rich.

Continuation/rework of: https://www.redhat.com/archives/libguestfs/2020-May/msg00020.html This is my approach, as I explained here: https://bugzilla.redhat.com/show_bug.cgi?id=1828952#c4 https://www.redhat.com/archives/libguestfs/2020-May/msg00035.html IOW: do not attempt to relabel if the guest is not enforcing, as it is either useless or may fail; few words more are in the comments of patch #3.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1212807 Since v1: - Combine the virt-builder detection code into virt-customize. - Enables us to delete Architecture and Uname modules completely. Rich.

Kali Linux is a Debian derivative, so add basic support for it by using most of the Debian code paths. The only exception is the crypto algorithm for passwords in passwd, which is always assumed as SHA512 (as Kali Linux is relatively new). --- customize/firstboot.ml | 2 +- customize/hostname.ml | 2 +- customize/password.ml | 2 +-

This shouldn't change the effect of this code. --- mlcustomize/SELinux_relabel.ml | 121 ++++++++++++++++++--------------- 1 file changed, 65 insertions(+), 56 deletions(-) diff --git a/mlcustomize/SELinux_relabel.ml b/mlcustomize/SELinux_relabel.ml index 44995df..5df1f08 100644 --- a/mlcustomize/SELinux_relabel.ml +++ b/mlcustomize/SELinux_relabel.ml @@ -28,65 +28,74 @@ module G = Guestfs

If the guest uses SELinux, then make sure to run a relabel (or at least schedule one) after the image build: this way the template is relabelled, or at least it will do that at the next boot, without the need for the user to ask for a relabel. This just covers the case of building a new image with no additional operations on it though. --- builder/website/centos.sh | 2 ++

--- customize/customize_run.ml | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/customize/customize_run.ml b/customize/customize_run.ml index 0f1d72a..cd4616c 100644 --- a/customize/customize_run.ml +++ b/customize/customize_run.ml @@ -338,15 +338,19 @@ exec >>%s 2>&1 if ops.flags.selinux_relabel then ( msg (f_"SELinux

Rewrite the relabel API to read the policy configured in the guest, invoking setfiles (added as part of the appliance, as part of policycoreutils) to relabel the specified root. In case of failure at any point of the process, a touch of .autorelabel in the root is tried as last-attempt measure to do the relabel. Considering that running SELinux tools in the appliance might be affected by the

Remove the logfiles configured by /etc/logrotate.d/*. Omit the logfile of "samba" and "sssd" which we removed them separately . Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- sysprep/sysprep_operation_logfiles.ml | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/sysprep/sysprep_operation_logfiles.ml

the description of the --selinux-relabel option suggests that it perform an immediate relabel, when in fact it may (and probably will) instead simply touch /.autorelabel on the image, which schedules a relabel operation for the next time the image boots. This can be surprising because it results both in an extended initial boot time *and* results in an automatic reboot (on some distributions).