targeted policy relabels *everything*?

[mark]

The admin I work with and I have been updated our CentOS servers to 6.6.
One server that's been running for years, with no issues (it is in
permissive, also), got updated...

Nov 25 17:26:56 Updated: kexec-tools-2.0.0-280.el6.x86_64
<many, many, many lines of asterisks elided>
 Nov 26 01:10:52 Updated: selinux-policy-targeted-3.7.19-260.el6.noarch
 Nov 26 01:10:56 Updated: coolkey-1.1.0-32.el6.x86_64

Yes, that *is* about 7.5 *hours* to install that policy. I can only guess
that for some reason, it decided to relabel the *ENTIRE* system.

Anyone have any idea *why*?

mark

[Tristan Santore]

On 26/11/14 18:44, [e-mail] wrote:
> The admin I work with and I have been updated our CentOS servers to 6.6.
> One server that's been running for years, with no issues (it is in
> permissive, also), got updated...
>
> Nov 25 17:26:56 Updated: kexec-tools-2.0.0-280.el6.x86_64
> <many, many, many lines of asterisks elided>
>  Nov 26 01:10:52 Updated: selinux-policy-targeted-3.7.19-260.el6.noarch
>  Nov 26 01:10:56 Updated: coolkey-1.1.0-32.el6.x86_64
>
> Yes, that *is* about 7.5 *hours* to install that policy. I can only guess
> that for some reason, it decided to relabel the *ENTIRE* system.
>
> Anyone have any idea *why*?
>   mark
>
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

Any large SANs mounted ? Or other large data volumes ? Then it could
take AGES!

Regards,
Tristan

[mark]

Tristan Santore wrote:
> On 26/11/14 18:44, [e-mail] wrote:
> > The admin I work with and I have been updated our CentOS servers to 6.6.
> > One server that's been running for years, with no issues (it is in
> > permissive, also), got updated...
> >
> > Nov 25 17:26:56 Updated: kexec-tools-2.0.0-280.el6.x86_64
> > <many, many, many lines of asterisks elided>
> >  Nov 26 01:10:52 Updated: selinux-policy-targeted-3.7.19-260.el6.noarch
> >  Nov 26 01:10:56 Updated: coolkey-1.1.0-32.el6.x86_64
> >
> > Yes, that *is* about 7.5 *hours* to install that policy. I can only
> > guess that for some reason, it decided to relabel the *ENTIRE* system.
> >
> > Anyone have any idea *why*?
> Any large SANs mounted ? Or other large data volumes ? Then it could
> take AGES!

Nope. A RAID 1 w/ 914G, 37% used. Don't tell me it tried to do any
NFS-mounted stuff, that I can't believe.

mark

[Tristan Santore]

On 26/11/14 18:53, [e-mail] wrote:
> Tristan Santore wrote:
> > On 26/11/14 18:44, [e-mail] wrote:
> > > The admin I work with and I have been updated our CentOS servers to 6.6.
> > > One server that's been running for years, with no issues (it is in
> > > permissive, also), got updated...
> > >
> > > Nov 25 17:26:56 Updated: kexec-tools-2.0.0-280.el6.x86_64
> > > <many, many, many lines of asterisks elided>
> > >  Nov 26 01:10:52 Updated: selinux-policy-targeted-3.7.19-260.el6.noarch
> > >  Nov 26 01:10:56 Updated: coolkey-1.1.0-32.el6.x86_64
> > >
> > > Yes, that *is* about 7.5 *hours* to install that policy. I can only
> > > guess that for some reason, it decided to relabel the *ENTIRE* system.
> > >
> > > Anyone have any idea *why*?
> >
> > Any large SANs mounted ? Or other large data volumes ? Then it could
> > take AGES!
>
> Nope. A RAID 1 w/ 914G, 37% used. Don't tell me it tried to do any
> NFS-mounted stuff, that I can't believe.
>   mark

<snip RPM SPEC FILE>
%post targeted
packages=`cat /usr/share/selinux/targeted/modules.lst`
if [ $1 -eq 1 ]; then
   %loadpolicy targeted $packages
   restorecon -R /root /var/log /var/run 2> /dev/null
else
   semodule -n -s targeted -r moilscanner -r mailscanner -r gamin -r
audio_entropy -r iscsid -r polkit_auth -r polkit -r rtkit_daemon -r
ModemManager -r telepathysofiasip -r passanger -r rgmanager -r aisexec
-r corosync -r pacemaker -r amavis -r clamav -r glusterfs 2>/dev/null
   %loadpolicy targeted $packages
   %relabel targeted
fi
exit 0
<snip RPM SPEC FILE>

Well, I am not sure and Miroslav and Dan will have to tell you exactly
what goes on, but it does look like it tries to force a full relabel. I
got this from the spec file, but I have never built the selinux-policy
myself, so not sure which %post section actually is applied, but suspect
as that is the targeted package option, it depends on the policy being
built and packaged.
I cannot seem to find the %relabel macro in the docs anywhere though,
probably looking the wrong place.

Dan and Miroslav can probably also clarify if the relabel applies to
remotely mounted storage or if there is an exception there.

I hope this helps.

Regards,

Tristan

[mark]

Tristan Santore wrote:
> On 26/11/14 18:53, [e-mail] wrote:
> > Tristan Santore wrote:
> > > On 26/11/14 18:44, [e-mail] wrote:
> > > > The admin I work with and I have been updated our CentOS servers to
> > > > 6.6. One server that's been running for years, with no issues (it is in
> > > > permissive, also), got updated...
> > > >
> > > > Nov 25 17:26:56 Updated: kexec-tools-2.0.0-280.el6.x86_64
> > > > <many, many, many lines of asterisks elided>
> > > >  Nov 26 01:10:52 Updated:
> > > > selinux-policy-targeted-3.7.19-260.el6.noarch
> > > >  Nov 26 01:10:56 Updated: coolkey-1.1.0-32.el6.x86_64
> > > >
> > > > Yes, that *is* about 7.5 *hours* to install that policy. I can only
> > > > guess that for some reason, it decided to relabel the *ENTIRE* system.
> > > >
> > > > Anyone have any idea *why*?
> > >
> > > Any large SANs mounted ? Or other large data volumes ? Then it could
> > > take AGES!
> >
> > Nope. A RAID 1 w/ 914G, 37% used. Don't tell me it tried to do any
> > NFS-mounted stuff, that I can't believe.
>
> <snip RPM SPEC FILE>
> %post targeted
> packages=`cat /usr/share/selinux/targeted/modules.lst`
> if [ $1 -eq 1 ]; then
>    %loadpolicy targeted $packages
>    restorecon -R /root /var/log /var/run 2> /dev/null
> else
>    semodule -n -s targeted -r moilscanner -r mailscanner -r gamin -r
> audio_entropy -r iscsid -r polkit_auth -r polkit -r rtkit_daemon -r
> ModemManager -r telepathysofiasip -r passanger -r rgmanager -r aisexec
> -r corosync -r pacemaker -r amavis -r clamav -r glusterfs 2>/dev/null
>    %loadpolicy targeted $packages
>    %relabel targeted
> fi
> exit 0
> <snip RPM SPEC FILE>
>
> Well, I am not sure and Miroslav and Dan will have to tell you exactly
> what goes on, but it does look like it tries to force a full relabel. I
> got this from the spec file, but I have never built the selinux-policy
> myself, so not sure which %post section actually is applied, but suspect
> as that is the targeted package option, it depends on the policy being
> built and packaged. I cannot seem to find the %relabel macro in the docs
> anywhere though, probably looking the wrong place.

This is a DHCP server, and a number of other things, but....
> Dan and Miroslav can probably also clarify if the relabel applies to
> remotely mounted storage or if there is an exception there.
>
> I hope this helps.

Thanks.

mark

[Daniel J Walsh]

On 11/26/2014 02:11 PM, [e-mail] wrote:
> Tristan Santore wrote:
> > On 26/11/14 18:53, [e-mail] wrote:
> > > Tristan Santore wrote:
> > > > On 26/11/14 18:44, [e-mail] wrote:
> > > > > The admin I work with and I have been updated our CentOS servers to
> > > > > 6.6. One server that's been running for years, with no issues (it is in
> > > > > permissive, also), got updated...
> > > > >
> > > > > Nov 25 17:26:56 Updated: kexec-tools-2.0.0-280.el6.x86_64
> > > > > <many, many, many lines of asterisks elided>
> > > > >  Nov 26 01:10:52 Updated:
> > > > > selinux-policy-targeted-3.7.19-260.el6.noarch
> > > > >  Nov 26 01:10:56 Updated: coolkey-1.1.0-32.el6.x86_64
> > > > >
> > > > > Yes, that *is* about 7.5 *hours* to install that policy. I can only
> > > > > guess that for some reason, it decided to relabel the *ENTIRE* system.
> > > > >
> > > > > Anyone have any idea *why*?
> > > >
> > > > Any large SANs mounted ? Or other large data volumes ? Then it could
> > > > take AGES!
> > >
> > > Nope. A RAID 1 w/ 914G, 37% used. Don't tell me it tried to do any
> > > NFS-mounted stuff, that I can't believe.
> >
> > <snip RPM SPEC FILE>
> > %post targeted
> > packages=`cat /usr/share/selinux/targeted/modules.lst`
> > if [ $1 -eq 1 ]; then
> >    %loadpolicy targeted $packages
> >    restorecon -R /root /var/log /var/run 2> /dev/null
> > else
> >    semodule -n -s targeted -r moilscanner -r mailscanner -r gamin -r
> > audio_entropy -r iscsid -r polkit_auth -r polkit -r rtkit_daemon -r
> > ModemManager -r telepathysofiasip -r passanger -r rgmanager -r aisexec
> > -r corosync -r pacemaker -r amavis -r clamav -r glusterfs 2>/dev/null
> >    %loadpolicy targeted $packages
> >    %relabel targeted
> > fi
> > exit 0
> > <snip RPM SPEC FILE>
> >
> > Well, I am not sure and Miroslav and Dan will have to tell you exactly
> > what goes on, but it does look like it tries to force a full relabel. I
> > got this from the spec file, but I have never built the selinux-policy
> > myself, so not sure which %post section actually is applied, but suspect
> > as that is the targeted package option, it depends on the policy being
> > built and packaged. I cannot seem to find the %relabel macro in the docs
> > anywhere though, probably looking the wrong place.
>
> This is a DHCP server, and a number of other things, but....
> > Dan and Miroslav can probably also clarify if the relabel applies to
> > remotely mounted storage or if there is an exception there.
> >
> > I hope this helps.
>
> Thanks.
>     mark
>
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

I have no idea why it would have done this.  There is an algorithm that
does a diff between the previous file context and the new and then
relabels the difference.

This could trigger a relabel of /usr or /var.   The relabel should
figure out you are on a NFS share and bale out.

Are there lots of files on a file system other then an NFS share?

[mark]

Daniel J Walsh wrote:
> On 11/26/2014 02:11 PM, [e-mail] wrote:
> > Tristan Santore wrote:
> > > On 26/11/14 18:53, [e-mail] wrote:
> > > > Tristan Santore wrote:
> > > > > On 26/11/14 18:44, [e-mail] wrote:
> > > > > > The admin I work with and I have been updated our CentOS servers to
> > > > > > 6.6. One server that's been running for years, with no issues (it is
> > > > > > in permissive, also), got updated...
> > > > > >
> > > > > > Nov 25 17:26:56 Updated: kexec-tools-2.0.0-280.el6.x86_64
> > > > > > <many, many, many lines of asterisks elided>
> > > > > >  Nov 26 01:10:52 Updated:
> > > > > > selinux-policy-targeted-3.7.19-260.el6.noarch
> > > > > >  Nov 26 01:10:56 Updated: coolkey-1.1.0-32.el6.x86_64
> > > > > >
> > > > > > Yes, that *is* about 7.5 *hours* to install that policy. I can only
> > > > > > guess that for some reason, it decided to relabel the *ENTIRE*
> > > > > > system.

<snip>
> > > > Nope. A RAID 1 w/ 914G, 37% used. Don't tell me it tried to do any
> > > > NFS-mounted stuff, that I can't believe.

<snip>
> I have no idea why it would have done this.  There is an algorithm that
> does a diff between the previous file context and the new and then
> relabels the difference.

That's more or less what I thought.
> This could trigger a relabel of /usr or /var.   The relabel should
> figure out you are on a NFS share and bale out.
>
> Are there lots of files on a file system other then an NFS share?

There are a fair number - find / | wc -l has been running for more than
five minutes now. One thing that is on this system are backups of /etc
from all 170+ servers and workstations, as well as of some home
directories....

But none of our other servers did that, and some include backup of home
directories.

mark
        mark