livecd-creator + selinux

[Eric Paris]

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....


3 errors/issues/quirks in building/running my livecd

1) libsemanage.dbase_llist_query: could not query record value
I'm told empty table, but I don't know what that means

2) /usr/sbin/semanage: Invalid prefix user
This pops out when semanage calls:
if selinux.security_check_context("system_u:object_r:%s_home_t:s0" % prefix) !=
0:
I assume this has to do with my bastardized /selinux inside the chroot.
Should we just make it != 0 && != -ENOENT or whatever the error is we
get there?

3) When booting I get 3 messages that say:
inode_doinit_with_dentry:  no dentry for dev=dm-0 ino=8345
The 3 inodes in question correspond to
/etc/udev
/etc/udev/rules.d
/etc/udev/rules.d/50-udev-default.rules

no clues where this is coming from.  I don't see it when I booted my
host system....



Anyway, at this point I want clues/help/suggestions on how to create my
hacked up /selinux inside the chroot.  Right now all I'm going is
creating it on the host system and bind mounting it into the chroot.  I
really should be creating this inside creator.py.  All that needs to be
inside it is 3 files.   copies of mls and policyvers from the host
system and load is a chrfile of /dev/null.  I could just create those in
the livecd image and they will get mounted on top of when its running,
but I don't want to waste the 50 bytes or whatever it would take.  Any
good suggests on how to build this temp?  Or where I could clean it out
later?

-Eric

[Stephen Smalley]

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.

>  
>  3 errors/issues/quirks in building/running my livecd
>  
>  1) libsemanage.dbase_llist_query: could not query record value
>  I'm told empty table, but I don't know what that means 
Looking at selinux-policy.spec, I see that it runs semanage login -l and
semanage user -l in its scriptlets.  If it does that and there are no
user or login entries defined yet, then you'd get that error I think.
Not sure if that means that something went wrong earlier or if it is
normal/legitimate.  Dan?

>  2) /usr/sbin/semanage: Invalid prefix user
>  This pops out when semanage calls:
>  if selinux.security_check_context("system_u:object_r:%s_home_t:s0" % prefix) !=
> 0:
>  I assume this has to do with my bastardized /selinux inside the chroot.
>  Should we just make it != 0 && != -ENOENT or whatever the error is we
>  get there? 
That should work, and this check should really be replaced by a new
libsemanage interface that checks against the target policy rather than
the host policy, like the mls enabled test.

>  3) When booting I get 3 messages that say:
>  inode_doinit_with_dentry:  no dentry for dev=dm-0 ino=8345
>  The 3 inodes in question correspond to
>  /etc/udev
>  /etc/udev/rules.d
>  /etc/udev/rules.d/50-udev-default.rules 
Happens when SELinux is setting up pre-existing inodes upon initial
policy load and it cannot find a dentry for the inode and thus cannot
invoke the ->getxattr method on it.   Likely harmless.  When/if the
files are subsequently looked up, the inodes should get set up at that
time upon the d_instantiate/d_splice_alias.

>  no clues where this is coming from.  I don't see it when I booted
> my
>  host system....
>  
>  
>  
>  Anyway, at this point I want clues/help/suggestions on how to create my
>  hacked up /selinux inside the chroot.  Right now all I'm going is
>  creating it on the host system and bind mounting it into the chroot.  I
>  really should be creating this inside creator.py.  All that needs to be
>  inside it is 3 files.   copies of mls and policyvers from the host
>  system and load is a chrfile of /dev/null.  I could just create those in
>  the livecd image and they will get mounted on top of when its running,
>  but I don't want to waste the 50 bytes or whatever it would take.  Any
>  good suggests on how to build this temp?  Or where I could clean it out
>  later?
>  
>  -Eric 
-- 
Stephen Smalley
National Security Agency

[Eric Paris]

#4 At the end of the rpm transaction when everything is installed it
calls restorecon and I get one for (I assume) every file almost all of
which look like:

/sbin/restorecon reset /srv context
system_u:object_r:var_t:s0->system_u:object_r:var_t:s0

Notice nothing changed?  Again I assume its my hack of a /selinux which
causes it and I'll try to run down why, but maybe someone else sees that
quickly.

-Eric

[Stephen Smalley]

On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote:
>  #4 At the end of the rpm transaction when everything is installed it
>  calls restorecon and I get one for (I assume) every file almost all of
>  which look like:
>  
>  /sbin/restorecon reset /srv context
> system_u:object_r:var_t:s0->system_u:object_r:var_t:s0
>  
>  Notice nothing changed?  Again I assume its my hack of a /selinux which
>  causes it and I'll try to run down why, but maybe someone else sees that
>  quickly. 
That suggests it is being called with the -f (force) flag from
e.g. /sbin/fixfiles.  selinux-policy.spec does a
	fixfiles -C file_contexts.pre restore

fixfiles -C does a diff between the old and new file contexts
configurations and applies restorecon to the result. There is some
serious magic in there, and it is all Dan's fault ;)

-- 
Stephen Smalley
National Security Agency

[Eric Paris]

On Thu, 2008-05-15 at 16:47 -0400, Stephen Smalley wrote:
>  On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote:
>  > #4 At the end of the rpm transaction when everything is installed it
>  > calls restorecon and I get one for (I assume) every file almost all of
>  > which look like:
>  > 
>  > /sbin/restorecon reset /srv context
> system_u:object_r:var_t:s0->system_u:object_r:var_t:s0
>  > 
>  > Notice nothing changed?  Again I assume its my hack of a /selinux which
>  > causes it and I'll try to run down why, but maybe someone else sees that
>  > quickly.
>  
>  That suggests it is being called with the -f (force) flag from
>  e.g. /sbin/fixfiles.  selinux-policy.spec does a
>  	fixfiles -C file_contexts.pre restore
>  
>  fixfiles -C does a diff between the old and new file contexts
>  configurations and applies restorecon to the result. There is some
>  serious magic in there, and it is all Dan's fault ;) 
ok, in the livecd-creator kickstart.py I see

        if os.path.exists(self.path("/sbin/restorecon")):
            self.call(["/sbin/restorecon", "-l", "-v",
"-r", "-F", "-e", "/proc", "-e",
"/sys", "-e", "/dev", "-e", "/selinux",
"/"])

So there is our -F.  Is there a way to get it to fix "user" without
getting it to fix "things that aren't wrong"

-Eric

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Paris wrote:
| On Thu, 2008-05-15 at 16:47 -0400, Stephen Smalley wrote:
|> On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote:
|>> #4 At the end of the rpm transaction when everything is installed it
|>> calls restorecon and I get one for (I assume) every file almost all of
|>> which look like:
|>>
|>> /sbin/restorecon reset /srv context
system_u:object_r:var_t:s0->system_u:object_r:var_t:s0
|>>
|>> Notice nothing changed?  Again I assume its my hack of a /selinux which
|>> causes it and I'll try to run down why, but maybe someone else sees that
|>> quickly.
|> That suggests it is being called with the -f (force) flag from
|> e.g. /sbin/fixfiles.  selinux-policy.spec does a
|> 	fixfiles -C file_contexts.pre restore
|>
|> fixfiles -C does a diff between the old and new file contexts
|> configurations and applies restorecon to the result. There is some
|> serious magic in there, and it is all Dan's fault ;)
|
| ok, in the livecd-creator kickstart.py I see
|
|         if os.path.exists(self.path("/sbin/restorecon")):
|             self.call(["/sbin/restorecon", "-l", "-v",
"-r", "-F",
"-e", "/proc", "-e", "/sys", "-e",
"/dev", "-e", "/selinux", "/"])
|
| So there is our -F.  Is there a way to get it to fix "user" without
| getting it to fix "things that aren't wrong"
|
| -Eric
|
Remove the -v

Although this looks wrong and makes no sense in restorecon/setfiles.


	/*
	 * Do not relabel the file if the matching specification is
	 * <<none>> or the file is already labeled according to the
	 * specification.
	 */
	if ((strcmp(newcon, "<<none>>") == 0) ||
	    (context && (strcmp(context, newcon) == 0) && !force)) {
		freecon(context);
		goto out;
	}

The !force check should be removed.   It makes no send to relabel in the
case of the context being the same or the context being none.

Should be


	/*
	 * Do not relabel the file if the matching specification is
	 * <<none>> or the file is already labeled according to the
	 * specification.
	 */
	if ((strcmp(newcon, "<<none>>") == 0) ||
	    (context && (strcmp(context, newcon) == 0)) {
		freecon(context);
		goto out;
	}


I will provide a patch and update.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkgtdmgACgkQrlYvE4MpobOtqgCgq0rDD7Be3h4Vb5hJDrvMebsf
> 6bAAoKaeIQqTknhhKaZHRehxsLQU4i0u
> =0LXA
> -----END PGP SIGNATURE-----

[Stephen Smalley]

On Thu, 2008-05-15 at 17:20 -0400, Eric Paris wrote:
>  On Thu, 2008-05-15 at 16:47 -0400, Stephen Smalley wrote:
>  > On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote:
>  > > #4 At the end of the rpm transaction when everything is installed it
>  > > calls restorecon and I get one for (I assume) every file almost all of
>  > > which look like:
>  > > 
>  > > /sbin/restorecon reset /srv context
> system_u:object_r:var_t:s0->system_u:object_r:var_t:s0
>  > > 
>  > > Notice nothing changed?  Again I assume its my hack of a /selinux which
>  > > causes it and I'll try to run down why, but maybe someone else sees that
>  > > quickly.
>  > 
>  > That suggests it is being called with the -f (force) flag from
>  > e.g. /sbin/fixfiles.  selinux-policy.spec does a
>  > 	fixfiles -C file_contexts.pre restore
>  > 
>  > fixfiles -C does a diff between the old and new file contexts
>  > configurations and applies restorecon to the result. There is some
>  > serious magic in there, and it is all Dan's fault ;)
>  
>  ok, in the livecd-creator kickstart.py I see
>  
>          if os.path.exists(self.path("/sbin/restorecon")):
>              self.call(["/sbin/restorecon", "-l", "-v",
> "-r", "-F", "-e", "/proc", "-e",
> "/sys", "-e", "/dev", "-e", "/selinux",
> "/"])
>  
>  So there is our -F.  Is there a way to get it to fix "user" without
>  getting it to fix "things that aren't wrong" 
I think we should change setfiles/restorecon to just not do that even
with -F.  IIRC, changing it to always invoke setfilecon even if the
contexts were the same was motivated by the problem we used to have
where the in-core label and the on-disk xattr could get out of sync.

Patch below.  Note that restorecon is just a link to setfiles that
presents a different default user interface and behaviors (ever since I
coalesced them).

Index: policycoreutils/setfiles/setfiles.c
===================================================================
--- policycoreutils/setfiles/setfiles.c	(revision 2879)
+++ policycoreutils/setfiles/setfiles.c	(working copy)
@@ -495,7 +495,7 @@
 	 * specification.
 	 */
 	if ((strcmp(newcon, "<<none>>") == 0) ||
-	    (context && (strcmp(context, newcon) == 0) && !force)) {
+	    (context && (strcmp(context, newcon) == 0))) {
 		freecon(context);
 		goto out;
 	}


-- 
Stephen Smalley
National Security Agency

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
| On Thu, 2008-05-15 at 17:20 -0400, Eric Paris wrote:
|> On Thu, 2008-05-15 at 16:47 -0400, Stephen Smalley wrote:
|>> On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote:
|>>> #4 At the end of the rpm transaction when everything is installed it
|>>> calls restorecon and I get one for (I assume) every file almost all of
|>>> which look like:
|>>>
|>>> /sbin/restorecon reset /srv context
system_u:object_r:var_t:s0->system_u:object_r:var_t:s0
|>>>
|>>> Notice nothing changed?  Again I assume its my hack of a /selinux which
|>>> causes it and I'll try to run down why, but maybe someone else sees
that
|>>> quickly.
|>> That suggests it is being called with the -f (force) flag from
|>> e.g. /sbin/fixfiles.  selinux-policy.spec does a
|>> 	fixfiles -C file_contexts.pre restore
|>>
|>> fixfiles -C does a diff between the old and new file contexts
|>> configurations and applies restorecon to the result. There is some
|>> serious magic in there, and it is all Dan's fault ;)
|> ok, in the livecd-creator kickstart.py I see
|>
|>         if os.path.exists(self.path("/sbin/restorecon")):
|>             self.call(["/sbin/restorecon", "-l", "-v",
"-r", "-F",
"-e", "/proc", "-e", "/sys", "-e",
"/dev", "-e", "/selinux", "/"])
|>
|> So there is our -F.  Is there a way to get it to fix "user" without
|> getting it to fix "things that aren't wrong"
|
| I think we should change setfiles/restorecon to just not do that even
| with -F.  IIRC, changing it to always invoke setfilecon even if the
| contexts were the same was motivated by the problem we used to have
| where the in-core label and the on-disk xattr could get out of sync.
|
| Patch below.  Note that restorecon is just a link to setfiles that
| presents a different default user interface and behaviors (ever since I
| coalesced them).
|
| Index: policycoreutils/setfiles/setfiles.c
| ===================================================================
| --- policycoreutils/setfiles/setfiles.c	(revision 2879)
| +++ policycoreutils/setfiles/setfiles.c	(working copy)
| @@ -495,7 +495,7 @@
|  	 * specification.
|  	 */
|  	if ((strcmp(newcon, "<<none>>") == 0) ||
| -	    (context && (strcmp(context, newcon) == 0) && !force)) {
| +	    (context && (strcmp(context, newcon) == 0))) {
|  		freecon(context);
|  		goto out;
|  	}
|
|
Same patch almost simultaneous, it must be right.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkgtduMACgkQrlYvE4MpobMn1gCg341q6CJQ2yDq7JPCcYVJn9ZQ
> /fcAn3I/rokQZcqP/S/ilO4fLFkTsRNB
> =ioXI
> -----END PGP SIGNATURE-----

[Douglas McClendon]

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 
As Bill said, the handling of rootpw is non-intuitive from a historical 
kickstart perspective.  I once suggested changing the kickstarts in 
livecd-tools to explicitly have rootpw lines (and then nuke the pw in 
%post), such that they would be generic fully automated kickstarts. 
People disagreed.  (though what you observed is a bug that can be fixed 
without heeding my suggestion)

> > 3) When booting I get 3 messages that say:
> > inode_doinit_with_dentry:  no dentry for dev=dm-0 ino=8345
> > The 3 inodes in question correspond to
> > /etc/udev
> > /etc/udev/rules.d
> > /etc/udev/rules.d/50-udev-default.rules
>  
>  Happens when SELinux is setting up pre-existing inodes upon initial
>  policy load and it cannot find a dentry for the inode and thus cannot
>  invoke the ->getxattr method on it.   Likely harmless.  When/if the
>  files are subsequently looked up, the inodes should get set up at that
>  time upon the d_instantiate/d_splice_alias. 
I've seen these messages forever, though didn't realize till now that 
they were an selinux related issue.  If they are truly harmless, can 
someone remove the code that spits out the message please?

FYI- note that what is going on with that file is that it is being 
modified by the initramfs before policy is loaded-

see do_live_from_base_loop in /usr/lib/livecd-creator/mayflower, i.e. 
stuff like this-

      echo "KERNEL==\"hd[a-z]\", BUS==\"ide\",
SYSFS{removable}==\"1\", 
ATTRS{media}==\"cdrom\", PROGRAM=\"/lib/udev/vol_id -l %N\", 
RESULT==\"\$CDLABEL\", SYMLINK+=\"live\"" >> 
/sysroot/etc/udev/rules.d/50-udev*



>  
> > no clues where this is coming from.  I don't see it when I booted my
> > host system....
> >
> >
> >
> > Anyway, at this point I want clues/help/suggestions on how to create my
> > hacked up /selinux inside the chroot.   
Out of curiosity, if someone feels like answering- are there any plans 
for selinux to support chroots in the sense of policy and even 
enabled/disabled being completely different between the host and the 
chroot?  Seems like "chroot /mnt/sysimage rpm <some rpm commoand>" ought 
to 'just work(tm)'.  But maybe I'm expecting too much functionality from 
a default fedora system.

-dmc

[Stephen Smalley]

On Thu, 2008-05-15 at 15:30 -0700, Douglas McClendon wrote:
>  Stephen Smalley wrote:
>  > On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote:
>  >> 3) When booting I get 3 messages that say:
>  >> inode_doinit_with_dentry:  no dentry for dev=dm-0 ino=8345
>  >> The 3 inodes in question correspond to
>  >> /etc/udev
>  >> /etc/udev/rules.d
>  >> /etc/udev/rules.d/50-udev-default.rules
>  > 
>  > Happens when SELinux is setting up pre-existing inodes upon initial
>  > policy load and it cannot find a dentry for the inode and thus cannot
>  > invoke the ->getxattr method on it.   Likely harmless.  When/if the
>  > files are subsequently looked up, the inodes should get set up at that
>  > time upon the d_instantiate/d_splice_alias.
>  
>  I've seen these messages forever, though didn't realize till now that 
>  they were an selinux related issue.  If they are truly harmless, can 
>  someone remove the code that spits out the message please? 
I'm ok with reducing them to KERN_DEBUG.  They do represent a
non-optimal aspect of the ->getxattr interface that we were hoping to
resolve some day (requires passing a dentry even though it immediately
extracts the inode and uses that for everything).  The only thing really
blocking us is CIFS reliance on pathname reconstruction ;)

>  FYI- note that what is going on with that file is that it is being 
>  modified by the initramfs before policy is loaded-
>  
>  see do_live_from_base_loop in /usr/lib/livecd-creator/mayflower, i.e. 
>  stuff like this-
>  
>        echo "KERNEL==\"hd[a-z]\", BUS==\"ide\",
> SYSFS{removable}==\"1\", 
>  ATTRS{media}==\"cdrom\", PROGRAM=\"/lib/udev/vol_id -l %N\", 
>  RESULT==\"\$CDLABEL\", SYMLINK+=\"live\"" >> 
>  /sysroot/etc/udev/rules.d/50-udev* 
Ah, thanks - that makes sense.  So the files get accessed before policy
load, are left with the unlabeled SID for that period of time, but
should get fixed up upon next lookup/d_instantiate.

>  > 
>  >> no clues where this is coming from.  I don't see it when I booted my
>  >> host system....
>  >>
>  >>
>  >>
>  >> Anyway, at this point I want clues/help/suggestions on how to create my
>  >> hacked up /selinux inside the chroot.  
>  
>  Out of curiosity, if someone feels like answering- are there any plans 
>  for selinux to support chroots in the sense of policy and even 
>  enabled/disabled being completely different between the host and the 
>  chroot?  Seems like "chroot /mnt/sysimage rpm <some rpm commoand>" ought
>
>  to 'just work(tm)'.  But maybe I'm expecting too much functionality from 
>  a default fedora system. 
I've given that some thought, but it appears to be rather complex to
support it, and it runs counter to our general goal of being able to
specify and enforce security goals for the entire platform (which is the
point of MAC).  I was thinking of introducing per-process policy
pointers that would initially all reference the same policy object, then
provide an interface to "unshare" policy analogous to other forms of
unshare(2) and clone(2), at which point a process could load a different
policy that would only apply to itself and its descendants.  However,
that doesn't resolve how to handle objects, and it doesn't deal with
accesses that cross the boundaries, especially as both processes (like
rpm) and files (like the files installed into the chroot environment)
will be accessible and accessed both from within the chroot and from
without.  In the end, I'm not sure it is worth it, and it certainly
won't be trivial.

-- 
Stephen Smalley
National Security Agency

[Eric Paris]

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

[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

[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.

[Bill Nottingham]

Eric Paris (eparis(a)redhat.com) said: 
>  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.... 
LiveCD has no root password. AFAIK, it just ignores that line.

Bill