Bug 773339
| Summary: | remove the 10-errors restriction when executing restorecon | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mr-4 <mr.dash.four> | ||||||||
| Component: | livecd-tools | Assignee: | Brian Lane <bcl> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 15 | CC: | adam.stokes, bcl, bruno, dan.carley+redhat, dhuff, dwalsh, Jasper.Hartline, katzj, mgrepl | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-08-07 14:56:28 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Mr-4
2012-01-11 15:07:14 UTC
Use setfiles instead of restorecon. Setfiles allows you to specify the path to the file_context file, and does not verify if the types exists. You might have to add mac_admin capability to the type generating your file context to make this work. (In reply to comment #1) > Use setfiles instead of restorecon. Setfiles allows you to specify the path to > the file_context file, and does not verify if the types exists. OK, I am a bit lost - since I mostly use this while executing this as part of building a livecd (where the chroot is some random directory under /var/tmp) how can I specify the path of a file_context file in advance? Give me an example please. > You might have > to add mac_admin capability to the type generating your file context to make > this work. I don't understand that either - elaborate please. I can't really see what is the rationale behind the introduction of this restriction? Have exactly 10 (or any other number) errors before restorecon bails out completely?! I mean really, what is the difference between 10 and 11, 15, 20, or even 100 errors? Why 10, exactly? And why have that at all to start with? This wasn't present in the previous versions of coreutils, why was it introduced now? In addition to what I have posted yesterday (Comment 2 above): setfiles won't be suitable as it expects "spec_file" to be specified as a command line parameter. From the man page: spec_file The specification file which contains lines of the following form regexp [ -type ] ( context | <<none>> ) The regular expression is anchored at both ends. The optional type field specifies the file type as shown in the mode field by the ls(1) program, e.g. -- to match only regular files or -d to match only directories. The context can be an ordinary security context or the string <<none>> to specify that the file is not to have its context changed. The last matching specification is used. If there are multiple hard links to a file that match different specifications and those specifications indicate different security contexts, then a warning is displayed but the file is still labeled based on the last matching specification other than <<none>>. I don't have this information as I am doing relabelling on the whole newly-built root system and don't know exactly what security context the file/path about to be checked/relabelled needs to be - this is part of the SELinux policy. As I already pointed out in my initial bug submission, the best solution would be to allow the security policy to be specified when restorecon runs and not to "default" to the the SELinux policy which exists on the host machine (as is the case with the present version). Livecd is supposed to do this automatically, and has been for a while. What AVC's are you seeing? Well, it doesn't as I already pointed out in my initial bug report - restorecon bails out after finding 10 "invalid/non-existent" contexts when doing relabelling starting from root (that is the LiveCD's own chroot!). As for the AVCs I am getting from livecd-creator - that is a separate issue altogether reported in Bug 735598 way back in September 2011 - see https://bugzilla.redhat.com/show_bug.cgi?id=735598. From looking at the change log, it looks like it was fixed in rpm -q python-imgcreate --changelog ... * Fri Feb 18 2011 Brian C. Lane <bcl> 16.1-1 - Version 16.1 (bcl) - Print reason for sudden exit (bcl) - Fix skipcopy usage with DVD iso (#644194) (bmj001) - Move selinux relabel to after %post (#648591) (bcl) - Add support for virtio disks to livecd (#672936) (bcl) - Support attached LiveOS devices as well as image files for LiveOS editing. (fgrose) - Check return value on udevadm (#637258) (bcl) A couple of things I need to mention: I use multiple %post sections in my kickstart file (with and without being chrooted). At the very last %post (while chrooted) I then execute "restorecon" to start relabelling the whole system from root (/) - this is done *manually*, i.e. I have a statement in that section and don't rely on livecd-creator to do that. Secondly, I am not sure what is the version of my livecd-tools package - I remember compiling it from source from rawhide because there was a nasty bug which could not recognise my boot partition ... yeah, just checked, it was Bug 739411, though I don't remember which rawhide version I used. Regardless of that, and assuming I use the most recent version of livecd-tools package, even if restorecon is executed *manually* from chrooted %post, it should be able to pick up the newly-installed policy on the livecd image and not rely on the one used on the host machine, which is what seems to be happening currently. restorecon is going to read /etc/selinux/POLICYTYPE/files/file_context. If you do not want it to use this file then you need to bind mount over it or run within a chroot, or use setfiles. Livecd-tools from fedora will execute a setfiles FILECONTEXT_PATH /, when it is done and change the labels to match the OS that. If you are seeing MAC_ADMIN avc's this would indicate that you are applying your new file context and the kernel does not know what those labels mean. The livecd-tools in Fedora also is able to setup the chroot environment that SELinux is disabled, which would cause a restorecon to fail silently but setfiles would still happen. Well, something is amiss then, because restorecon is executed from %post in a chrooted environment, therefore /etc/selinux/targeted/files/file_context should contain that file from my chrooted newly-installed (customised) selinux-policy-targeted package and the custom types will then be recognised. This, evidently, does not happen. What I will do in about an hour or so (when I finally get home) is to recompile and reinstall the latest livecd-tools package from rawhide (if I use an older version on my machine) and re-run this again. One thing I forgot to mention though - due to Bug 735598 I am executing "echo 0 > /selinuc/enforce" prior to starting livecd-creator because I just got fed up with all the AVC's I am getting and livecd-creator can't function properly otherwise. That bug has been sitting there for more than 3 months! OK, I've had the chance to run over this yet again. My findings follow (again, all this is executed when I have SELinux in permissive mode because of Bug 735598): In my kickstart file I've put a marker "read -p 'Press RET key to continue...'" (i.e. pause, so that I could check things up) in the post section immediately after all packages are installed, but before I run restorecon "manually". This would have given me the chance to see my audit and other logs so that I know what is happening. I've originally had livecd-tools-17.1-1.fc15.x86_64 installed and even though I recompiled and upgraded to the latest version from rawhide (livecd-tools-17.3-1.fc15.x86_64) there were no (visible) changes to the outcome. This is what I've had in my last %post section: %post [...] #must be the LAST action - selinux relabelling /sbin/restorecon -ripF / When I ran livecd-creator and reached the "Press RET ..." prompt (i.e. at the point when I've had all of my packages installed, but before my own restorecon is executed), I checked my messages logs - nothing of interest, then my audit logs where I found over a 1000 lines of various SELINUX_ERR, ADD_USER, ADD_GROUP etc messages which, by the look of things, must have been triggered when livecd-creator installed my selinux-policy-targeted package. I could attach these logs if there is any interest, just let me know. At the same stage I've got quite a few AVCs, very much like the ones I reported in Bug 735598. Now, to continue to the 2nd stage when my "manual" restorecon from %post is executed, I pressed return and after a while I've got exactly the same error as indicated in the initial report of this bug above: Press RET key to continue... *************************************** /etc/selinux/targeted/contexts/files/file_contexts: line XX has invalid context system_u:object_r:YY:s0 [x10] Exiting after 10 errors. [...] umount: /var/tmp/imgcreate-GQGbkM/install_root/selinux/load: not found When all was completed and I've had my iso image I then looked in my audit logs again (there was nothing of note in my messages file) and spotted just one audit record: type=FS_RELABEL msg=audit(1326756383.359:35287): user pid=6773 uid=0 auid=500 ses=1 subj=unconfined_u:unconfined_r:setfiles_mac_t:s0-s0:c0.c1023 msg='op=mass relabel: exe="/sbin/setfiles" hostname=? addr=? terminal=pts/0 res=success' That was it! So, it seems that my "manual" restorecon execution has not completed as it bails out after 10 errors, but I already knew that... One you should not be seeing the load_policy on your host machine, since that could cause your host machine to go nuts. Imagine building a F15 livecd on a F17 box, you would install an old policy and cause lots of types to no longer be defined. This is why the stuff going on within the livecd is supposed to think SELinux is disabled. If the chroot within the livecd thinks SELinux is disabled restorecon should not put out any errors, and should just exit. The FS_RELABEL should also probably not show up on the host because this would indicate the host is being relabeled. setfiles FC / causes this audit message to show up. I guess you could check if the choot thinks SELinux is disabled by executing getenforce within your post. If you run in enforcing mode what happens? (In reply to comment #11) > One you should not be seeing the load_policy on your host machine, since that > could cause your host machine to go nuts. Imagine building a F15 livecd on a > F17 box, you would install an old policy and cause lots of types to no longer > be defined. This is why the stuff going on within the livecd is supposed to > think SELinux is disabled. What does that mean exactly - are you suggesting I should not be running restorecon within %post? The load_policy error message is displayed just before livecd-creator finishes its job - this message is shown on the console. The FS_RELABEL message *is* in the audit logs on the host machine. > If the chroot within the livecd thinks SELinux is > disabled restorecon should not put out any errors, and should just exit. The > FS_RELABEL should also probably not show up on the host because this would > indicate the host is being relabeled. setfiles FC / causes this audit message > to show up. Yeah, and I should not have seen the 10-errors limit message either. restorecon should not have bailed out etc etc ... Do you need me to go on...It is obvious that something is wrong and I need to find out what that is. (In reply to comment #12) > I guess you could check if the choot thinks SELinux is disabled by executing > getenforce within your post. SELinux *is* disabled on the host (it is running in permissive mode) - please refer to Comment 9 and Comment 10 I posted earlier. > If you run in enforcing mode what happens? Please refer to Bug 735598. I cannot do anything meaningful if SELinux is in enforced mode due to that bug. Ok the messages above were more for the livecd-tools maintainer. I just want to make sure that there seems to be an information leak between the host and the chroot, that should not happen, which is causing your problems. Also the restorecon that you are executing within your post should not be needed, since the livecd should be relabeling everything within the chroot when it is done. So at most it is a waste of time. (In reply to comment #15) > Ok the messages above were more for the livecd-tools maintainer. I just want > to make sure that there seems to be an information leak between the host and > the chroot, that should not happen, which is causing your problems. It wasn't clear from your comments who these were addressed to, so, naturally, I assumed that they were aimed at me, hence the response. > Also the restorecon that you are executing within your post should not be > needed, since the livecd should be relabelling everything within the chroot when > it is done. So at most it is a waste of time. I disagree entirely! The "automatic" mass-relabelling, if it happens at all, is done, *once*, as soon as the selinux-policy-targeted package is installed. This is evident from the timings I get in the audit logs as well as my CPU load. When such mass-relabelling takes place the CPU load peaks - for a noticeable period - during that time. I can confirm that *no* such mass-relabelling takes place when %post has completed - maybe there should be a provision for this, in which case you would be right that I won't need to do that "manually", but until that happens I am stuck and have no other, properly working, alternative. It is also worth noting that after selinux-policy-targeted I have many other packages installed *and* I also have numerous custom scripts which are executed creating other files on that chrooted system, as well as unpacking various tar.{gz,xz} archives from the host system into it. I run "manual" relabelling of the entire chrooted file system not just because I enjoy hammering my CPU, but because I had SELinux relabelling issues as a result of the activities I described in the previous paragraph. livecd runs setfiles on the target after %post Please attach your logs from your build, they may reveal more about what is going on. What logs would you require? Also, would you like me to run livecd-creator with some specific options to get extra stuff logged in? Pass it -d -v --logfile=build.log I decided that it is better if I could prepare a small test case and build everything from scratch so that the various "custom" tweaks I have on my host environment are eliminated from the build process as much as possible. I am attaching 3 files: 1. policy-targeted-patches.tar.xz contains patches made to the "standard" 3.9.16-48 (targeted) policy. 2. livecd-creator-logs.tar.xz contains various logs (described below) accumulated during the build process. 3. ks-test.cfg - my kickstart file used to build the image The policy patches are self-explanatory, though the .spec patch contains a complete solution to Bug 716635 which I submitted more than 8 months ago (the bug is still open!). With these patches I created a separate policy module introducing 17 new SE Linux types which form part of the "new" policy (the actual trigger for the errors). The kickstart file installs the "bare minimum" (in Fedora's own standards) of 155 packages. In this file I separate the build process into 3 stages, by input from the console, allowing me to capture the various logs accumulated during each stage. So, the 3 stages are: 1. Packages Installed - the stage when all packages are installed, but before I execute anything the %post section (custom logic, create additional files etc). 2. Manual relabelling - this is the very last statement of my %post section when "manual" relabelling takes place. Before that I create a bunch of temporary files on which the context should be reset with the newly-defined SE Linux types. 3. The last stage is when %post is completed. In this stage, I thought - wrongly (humble pie at the ready!) - that no relabelling takes place. Well, apparently, it does. Not only that, but it turns out that all the errors I have been getting and which I reported on this bug are actually triggered by the auto-relabelling process by livecd-creator and not by the "manual" relabelling as I first thought. This is evident from the attached logs. My own (manual) relabelling passes with flying colours! In addition, in order to help fix Bug 735598 as well, I ran livecd-creator using SELinux in both enforcing (livecd-creator failing miserably here as evident from the logs) and permissive modes. The commands I have executed and the log files produced were as follows: Enforced ~~~~~~~~ setarch i686 livecd-creator -d -v --logfile=build-enforced.log -c ~/ks-test.cfg -f test attached messages-enforced-packages-installed.log (this is tail-ed output from /var/log/messages) attached audit-enforced-packages-installed.log (my audit.og file with the relevant SELinux messages included) [stage 2] attached audit-enforced-manual-relabelled.log [stage 3] attached audit-enforced-post-relabelled.log attached kickstart-console-enforced.log (console output from livecd-creator) attached build-enforced.log (build.log from livecd-creator) Permissive ~~~~~~~~~~ setenforce 0 setarch i686 livecd-creator -d -v --logfile=build-permissive.log -c ~/ks-test.cfg -f test attached messages-permissive-packages-installed.log attached audit-permissive-packages-installed.log [atage 2] attached messages-permissive-manual-relabelled.log attached audit-permissive-manual-relabelled.log [stage 3] (no SELinux errors were logged to audit log at this stage, though everything was displayed on the console, don't know why that is!) attached kickstart-console-permissive.log attached build-permissive.log Let me know if you need additional information in order to progress this. Created attachment 559393 [details]
SELinux policy patches
SELinux policy patches
Created attachment 559394 [details]
livecd-creator logs
livecd-creator logs
Created attachment 559395 [details]
kickstart configuration file
kickstart configuration file
I'm seeing the same symptoms as this when building CentOS 5 images from F16, livecd-tools / python-imgcreate 16.10.1.fc16
/etc/selinux/targeted/contexts/files/file_contexts: line 120 has invalid context system_u:object_r:openvpn_script_exec_t:s0
/etc/selinux/targeted/contexts/files/file_contexts: line 530 has invalid context system_u:object_r:hald_var_run_t:s0
/etc/selinux/targeted/contexts/files/file_contexts: line 531 has invalid context system_u:object_r:hald_log_t:s0
/etc/selinux/targeted/contexts/files/file_contexts: line 571 has invalid context system_u:object_r:hald_var_run_t:s0
/etc/selinux/targeted/contexts/files/file_contexts: line 603 has invalid context system_u:object_r:hotplug_var_run_t:s0
/etc/selinux/targeted/contexts/files/file_contexts: line 604 has invalid context system_u:object_r:hotplug_etc_t:s0
/etc/selinux/targeted/contexts/files/file_contexts: line 605 has invalid context system_u:object_r:hald_var_lib_t:s0
/etc/selinux/targeted/contexts/files/file_contexts: line 813 has invalid context system_u:object_r:hotplug_exec_t:s0
/etc/selinux/targeted/contexts/files/file_contexts: line 846 has invalid context system_u:object_r:hald_cache_t:s0
Exiting after 10 errors.
It appears that the call to "/sbin/setfiles" within imgcreate.kickstart.SelinuxConfig.relabel() uses the setfiles binary from *outside* the chroot (F16) with the file_contexts from *inside* the chroot (Cent5).
I'm guessing that subprocess.call() resolves the executable before the os.chroot() call given to preexec_fn. Adding the following lines to SelinuxConfig.relabel:
print "DEBUG: /bin/uname -a"
self.call(["/bin/uname", "-a"])
print "DEBUG: /bin/cat /etc/redhat-release"
self.call(["/bin/cat", "/etc/redhat-release"])
Produces the following output to affirm this theory:
DEBUG: /bin/uname -a
Linux ip-10-227-91-113 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1 21:10:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
DEBUG: /bin/cat /etc/redhat-release
CentOS release 5.8 (Final)
It would follow that this also affects other commands passed through self.call() in imgcreate.kickstart with less obvious symptoms.
Dan, I don't think that's the problem. the redhat-release is clearly the CentOS one from inside the chroot. uname inside a chroot is going to return the kernel of the host system, not the one installed in the chroot. Yeah, that was a stupid example. Using something baked-in like "rpm --version" does work as expected. What originally led me to think that is the same errors can be produced by calling setfiles against the mounted image and outside of a chroot: # mount -o loop centos58-x86_64.img /mnt # /sbin/setfiles /mnt/etc/selinux/targeted/contexts/files/file_contexts /mnt /mnt/etc/selinux/targeted/contexts/files/file_contexts: line 120 has invalid context system_u:object_r:openvpn_script_exec_t:s0 /mnt/etc/selinux/targeted/contexts/files/file_contexts: line 530 has invalid context system_u:object_r:hald_var_run_t:s0 /mnt/etc/selinux/targeted/contexts/files/file_contexts: line 531 has invalid context system_u:object_r:hald_log_t:s0 ... Exiting after 10 errors. However this works fine: # chroot /mnt /sbin/setfiles /etc/selinux/targeted/contexts/files/file_contexts / /sbin/setfiles: labeling files under / matchpathcon_filespec_eval: hash table stats: 12545 elements, 12545/65536 buckets used, longest chain length 1 /sbin/setfiles: Done. Completely disregard comment 24. The significant difference in comment 26 is that imgcreate still has the bind mounts for "/sys/fs/selinux" and "/sys/fs/selinux/load" when setfiles is executed within the chroot. BTW In F16 and F17 making /sys/fs/selinux/ read/only will cause SELinux library to report SELinux is disabled. Looks like it does correlate with the bind mount. It is R/W. Does setfiles verify the spec file contents against sysfs/selinuxfs? I've also hit two other problems: - The user context on some files like /etc/selinux/config and /etc/selinux/targeted/contexts/files/file_contexts is left as "unconfined_u". After booting the image the type becomes "unlabeled_t" and plenty of things break. Adding the -F argument to setfiles appears to catch these, but from the description of the argument in the man page I don't understand why. - file_contexts doesn't catch the /home directories of any new users created. It also doesn't catch /root on EL5. A second call with file_contexts.homedirs mops these up. I've taken to hacking around these for the time being with the following %post script: %post --erroronfail mount -t tmpfs -o size=1 tmpfs /sys/fs/selinux mount -t tmpfs -o size=1 tmpfs /selinux /sbin/setfiles -F -e /proc -e /sys -e /dev -e /selinux /etc/selinux/targeted/contexts/files/file_contexts / /sbin/setfiles -F /etc/selinux/targeted/contexts/files/file_contexts.homedirs home/ /root/ umount -t tmpfs /sys/fs/selinux /selinux %end I'd be interested to know what the correct fix is and whether all of the above is necessary. Happy to provide more any more info if it helps. Furthermore the bind mount on /var/cache/yum results in the wrong file context within the image. Is there a reason, perhaps for other platforms, that kickstart.SelinuxConfig(self._instroot).apply(ksh.selinux) isn't called after ImageCreator.__destroy_selinuxfs() and ImageCreator._undo_bindmounts()? I guess you could try that. Not sure if it is a good or bad idea. This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |