livecd-creator + selinux

[Stephen Smalley]

On Fri, 2008-05-16 at 14:25 -0400, Eric Paris wrote:
> On Thu, 2008-05-15 at 15:30 -0400, Stephen Smalley wrote:
> > On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote:
> > > So I'm still stumbling along in the dark trying to get livecd-creator to
> > > build me a nice new F10 image inside an F10 host.  I've actually got an
> > > image that built and runs, but not without its issues.
> > > 
> > > my kickstart file has:
> > > auth --enableshadow --enablemd5
> > > rootpw redhat
> > > 
> > > but the livecd always has x for the password in /etc/password and * for
> > > the password in /etc/shadow.  No ideas here I must admit.  I'm highly
> > > doubtful its selinux since it happens in permissive and enforcing.  I
> > > have just been booting into single user, calling passwd, init 3, and
> > > logging in to play around in my live image....
> > 
> > No ideas here - hopefully the livecd folks can help you with that one.
> 
> turns out it was an selinux issue.
> 
> passwd does 2 different checks to see if selinux is going to allow it.
> Dan, what were you thinking?  I see your name written all of this.
> 
> Anyway selinux_check_passwd_access() calls security_getenforce() and
> allows things if it gets 0.  Since security_getenforce can't
> open /selinux/enforce (it doesn't exist) it returned -1, we then
> proceeded to try to do the access check which obviously also bombed (do
> to another ENOENT) and passwd gave us that useless "Only root can do
> that" message.
> 
> First try was to change selinux_check_passwd_access() to return a
> success if security_getenforce() < 1.  Which then turned up that passwd
> has its own secondary check (WTF?) called check_selinux_access() which
> basically did the same thing as the libselinux function.  I changed it
> to use < 1 and finally got passwd to run inside my chroot.
> 
> I think the best solution here is to explicitly set a /selinux/enforce =
> 0 in the chroot rather than hack everything that could possibly call
> security_getenforce()   what do others think?

Given the approach being taken here, that is likely harmless, as all we
care about within the chroot is that SELinux is seen as enabled (which
is independent of enforce) and that files are labeled properly.

-- 
Stephen Smalley
National Security Agency