similar to: The role of /.autorelabel

[ 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

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

Do SELinux relabelling properly.

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 +++++++++++++++++++++++++++++++++++++++++++

I'm trying to find a way to exclude file systems during the autorelabel process. I have a file system (/exports) that has tens of millions of files on it and I *know* I don't want it relabeled. I've tried semanage fcontext -a -t "<<none>>" "/exports(/.*)?" and it seems to insist on relabeling that file system. I also tried to see if there was a

--- 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

On Tuesday, 5 May 2020 17:44:15 CEST Richard W.M. Jones wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1828952#c2 I think we need to do a different approach than this patch. The biggest thing is that currently we check only SELINUXTYPE for the actual policy, however we do not check SELINUX in case SELinux is in enforcing mode at all. IMHO we rather need to read

I have a serious privileges problem that is making it impossible to serve python pages on a CentOS server. I have tried to resolve this problem in my last post, but now it appears that interest has petered out. I'm desperate and hoping someone on this list can help. [Fri Nov 06 11:50:40 2009] [error] [client 66.248.168.98] (2)No such file or directory: exec of

Tried just the selinux list yesterday, no answers, so I'm trying again. I partitioned GPT, and formatted, as xfs, a large (3TB) drive on a CentOS 6 system, which has selinux in permissive mode. I then moved the drive to a CentOS 5 system. When we run a copy (it mirror-copies from another system), we get a ton of errors. I discovered that the CentOS 5 system was enforcing. I changed it to

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

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.

I'm seeing this every hour when the hourly cron job runs NULL security context for user, but SELinux in permissive mode, continuing () I've tried fixfiles but obviously I'm missing something.... Any SELinux gurus that can point me in the right direction? Thanks Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: rkampen.vcf Type: text/x-vcard

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.

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

Ok, so if anyone runs into a problem where dovecot reports chdir(/home/BLAH) failed with uid NNN: Permission denied in Fedora Core 4 or otherwise, it seems to be a SELinux problem. Turn OFF SELinux and the problem goes away. -------------- next part -------------- An HTML attachment was scrubbed... URL:

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).

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. Recap: SELinux file labels -------------------------- SELinux requires that files have labels. Access to a file is controlled by the label on that file.

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(-) >

https://bugzilla.redhat.com/show_bug.cgi?id=1828952#c2 If SELINUXTYPE is set to some value other than targeted then we look for a directory /etc/selinux/<SELINUXTYPE> which does not exist. However this should not cause a fatal error. Using setfiles to do the relabelling immediately is a nice-to-have, but we can fallback to using autorelabel if we're unable to achieve it. ---