systemd: Failed to initialize SELinux context: Permission denied

[John.Florian at dart.biz]

Daniel J Walsh <dwalsh at redhat.com> wrote on 12/07/2012 14:40:55:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 12/07/2012 11:26 AM, John.Florian at dart.biz wrote:
> > Daniel J Walsh <dwalsh at redhat.com> 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 at dart.biz 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20121207/4b4c1191/attachment.html>