>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/07/2012 11:26 AM, John.Florian@xxxxxxxx wrote:
> > Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote on 12/07/2012 10:46:11:
> >>
> >> On 12/07/2012 08:44 AM, Bruno Wolff III wrote:
> >>> On Fri, Dec 07, 2012 at 08:22:10 -0500, John.Florian@xxxxxxxx wrote:
> >>>>
> >>>> Thinking selinux might be preventing the relabel from happening (?!?)
> >>>> I rebooted with selinux=0 so that I could reconfig
> >>>> /etc/sysconfig/selinux having SELINUX=permissive, touched
> >>>> /.autorelabel and rebooted again. This time I saw the relabel process
> >>>> do its thing and trigger a reboot. I then went back to reconfig
> >>>> /etc/sysconfig/selinux having SELINUX=enforcing, rebooted and all
> >>>> seemed well, finally.
> >>>
> >>> The autorelabel is supposed to happen early in the boot process and I
> >>> think it is supposed to work even if you system normally comes up in
> >>> enforcing mode. So that sounds like a bug.
> >>>
> >>> (You can come up in permissive mode using the enforcing=0 kernel
> >>> parameter. This is a bit more convenient in some cases for a one time
> >>> boot, than changing the selinux configuration.)
> >>>
> >>> This is generally the safeest way to relabel as you don't want
> >>> processes that started with the wrong context creating more incorrectly
> >>> labelled files while you are trying to fix things up (with say
> >>> restorecon).
> >>>
> >>>> So, I'm all good now, but there may be some bugs in that "relabel
> >>>> should happen automatically" bit. -- John Florian
> >> Yes systemd is supposed to set the machine into permissive mode for the
> >> relabel, but I guess if the machine is totally mislabeled, systemd might
> >> be prevented from doing this, although I would figure systemd would be
> >> running as the kernel label. Bottom line this would be difficult to
> >> diagnose what happened to force you to relabel in permissive mode.
> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment:
> >> Using GnuPG with undefined - http://www.enigmail.net/
> >>
> >> iEYEARECAAYFAlDCD0MACgkQrlYvE4MpobN0gACeIRh+3rBTIXX/GVvxxIrMnvUq
> >> 1EUAoNfsFpd+zYOiPq9h/+fXol6j3mLO =kYu4 -----END PGP SIGNATURE-----
> >
> >
> > I agree this would be hard to diagnose. I doubt I could reproduce the
> > situation given all this poor system has been through. That and I'm
> > already up to my ears in alligators trying to port our software stack over
> > to what's becoming F18.
> >
> > As I stated, it's no longer a problem for me, so I'm happy. I just wanted
> > to make sure those who would want to know had been informed.
> >
> > -- John Florian
> >
> >
> If you have a selinux-policy version of 57,58,59 it could have also failed on
> the relabel in enforcing mode, since there was a major bug in policy that
> should be fixed by -60.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlDCRkYACgkQrlYvE4MpobNVEwCg3sx2OlPipwq2YHlS+fxsozCb
> ayUAn2r56PioTL8Swc0nG9cglnpOT3tY
> =Bds9
> -----END PGP SIGNATURE-----
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.
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?
--
John Florian
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
