livecd-creator + selinux

[Daniel J Walsh]

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?
> 
> -Eric
> 
Well the code was written 100 years ago or it feels that way anyways.  I
think the multiple checks are to see if you are root when changing a
password and to check whether the domain executing passwd has the rootok
passwd access.