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
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
- 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?
- /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.
- 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
#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
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 ;)
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
-----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.
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; }
-----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.
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)
- 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
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:
- 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.
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
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.
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.
Eric Paris (eparis@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
selinux@lists.fedoraproject.org
-
Bill Nottingham -
Daniel J Walsh -
Douglas McClendon -
Eric Paris -
Stephen Smalley