<tt><font size=2>Daniel J Walsh <dwalsh@redhat.com> wrote on 12/07/2012
14:40:55:<br>
> <br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA1<br>
> <br>
> On 12/07/2012 11:26 AM, John.Florian@dart.biz wrote:<br>
> > Daniel J Walsh <dwalsh@redhat.com> wrote on 12/07/2012
10:46:11:<br>
> >> <br>
> >> On 12/07/2012 08:44 AM, Bruno Wolff III wrote:<br>
> >>> On Fri, Dec 07, 2012 at 08:22:10 -0500, John.Florian@dart.biz
wrote:<br>
> >>>> <br>
> >>>> Thinking selinux might be preventing the relabel
from happening (?!?)<br>
> >>>> I rebooted with selinux=0 so that I could reconfig<br>
> >>>> /etc/sysconfig/selinux having SELINUX=permissive,
touched<br>
> >>>> /.autorelabel and rebooted again. This time I saw
the relabel process<br>
> >>>> do its thing and trigger a reboot. I then went
back to reconfig<br>
> >>>> /etc/sysconfig/selinux having SELINUX=enforcing,
rebooted and all<br>
> >>>> seemed well, finally.<br>
> >>> <br>
> >>> The autorelabel is supposed to happen early in the boot
process and I<br>
> >>> think it is supposed to work even if you system normally
comes up in<br>
> >>> enforcing mode. So that sounds like a bug.<br>
> >>> <br>
> >>> (You can come up in permissive mode using the enforcing=0
kernel<br>
> >>> parameter. This is a bit more convenient in some cases
for a one time<br>
> >>> boot, than changing the selinux configuration.)<br>
> >>> <br>
> >>> This is generally the safeest way to relabel as you don't
want<br>
> >>> processes that started with the wrong context creating
more incorrectly<br>
> >>> labelled files while you are trying to fix things up
(with say<br>
> >>> restorecon).<br>
> >>> <br>
> >>>> So, I'm all good now, but there may be some bugs
in that "relabel<br>
> >>>> should happen automatically" bit. -- John Florian<br>
> >> Yes systemd is supposed to set the machine into permissive
mode for the <br>
> >> relabel, but I guess if the machine is totally mislabeled,
systemd might<br>
> >> be prevented from doing this, although I would figure systemd
would be<br>
> >> running as the kernel label. Bottom line this would
be difficult to<br>
> >> diagnose what happened to force you to relabel in permissive
mode. <br>
> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)
Comment:<br>
> >> Using GnuPG with undefined - </font></tt><a href=http://www.enigmail.net/><tt><font size=2>http://www.enigmail.net/</font></tt></a><tt><font size=2><br>
> >> <br>
> >> iEYEARECAAYFAlDCD0MACgkQrlYvE4MpobN0gACeIRh+3rBTIXX/GVvxxIrMnvUq
<br>
> >> 1EUAoNfsFpd+zYOiPq9h/+fXol6j3mLO =kYu4 -----END PGP SIGNATURE-----<br>
> > <br>
> > <br>
> > I agree this would be hard to diagnose. I doubt I could
reproduce the<br>
> > situation given all this poor system has been through. That
and I'm<br>
> > already up to my ears in alligators trying to port our software
stack over<br>
> > to what's becoming F18.<br>
> > <br>
> > As I stated, it's no longer a problem for me, so I'm happy. I
just wanted<br>
> > to make sure those who would want to know had been informed.<br>
> > <br>
> > -- John Florian<br>
> > <br>
> > <br>
> If you have a selinux-policy version of 57,58,59 it could have also
failed on<br>
> the relabel in enforcing mode, since there was a major bug in
policy that<br>
> should be fixed by -60.<br>
> -----BEGIN PGP SIGNATURE-----<br>
> Version: GnuPG v1.4.12 (GNU/Linux)<br>
> Comment: Using GnuPG with undefined - </font></tt><a href=http://www.enigmail.net/><tt><font size=2>http://www.enigmail.net/</font></tt></a><tt><font size=2><br>
> <br>
> iEYEARECAAYFAlDCRkYACgkQrlYvE4MpobNVEwCg3sx2OlPipwq2YHlS+fxsozCb<br>
> ayUAn2r56PioTL8Swc0nG9cglnpOT3tY<br>
> =Bds9<br>
> -----END PGP SIGNATURE-----<br>
</font></tt>
<br>
<br><font size=2 face="sans-serif">Believe it or not, I had enough ssh
history in konsole on that machine to scroll back and see where I was doing
the upgrade and lo and behold, it was on -59 at the time.</font>
<br>
<br><font size=2 face="sans-serif">Would it make sense to capture the policy
version in the audit.log alongside those AVCs? Seems like that would
be helpful when reviewing them. Or would it be useless without some
sort of "tainted" flag like the kernel uses to indicate when
the policy had been augmented in some way?<br>
--<br>
John Florian</font>
<br>