Bug 202375
Summary: | Changes made to security policy lost after reboot | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Bentley <david.r.bentley> | ||||
Component: | system-config-securitylevel | Assignee: | Chris Lumens <clumens> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | dwalsh, urkle | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-08-29 16:02:02 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
David Bentley
2006-08-13 21:39:30 UTC
What type of policy are you using - strict or targeted? What are the contents of /etc/selinux/<policy type>/modules/active/booleans.local? I am using targeted. The content of the file after a reboot when the changes are lost is as follows ;- # This file is auto-generated by libsemanage # Please use the semanage command to make changes allow_ypbind=0 I will now log out as root and back in as a normal userand make the changes originally described and then log bak in as root and if there is any change to the above file contents I will post it in a further comment immediately. I can confirm that after making changes as a normal user they do take effect and remain in effect as the root user and that the content of the file does not change as a result of checking the above mentioned boxes. On reboot the boxes ticked are empty again and therefore the changes do not stick. Te file has the following permissions set owner root r w group root r others r and is labeled system_u:object_r:semanage_store_t:s0 Dan - any thoughts here? I did some tests earlier today and the booleans I selected were being added to booleans.local, and getsebool gave me the correct values. I confirmed that setsebool was being run with the correct arguments. In Rawhide/FC5 the policy is being rebuilt on each change. setsebool -P allow_ypbind=0 should update the policy in order to survice a reboot. the local files are no longer used, You should use the commands. On my local machine, the booleans.local file is still getting written out (s-c-securitylevel has no references to that file), but setsebool is being run correctly. This is after updating to rawhide today, but perhaps I have something old still around? David - is /etc/selinux/targeted/policy/policy* getting updated? Check with ls -l and make sure the date stamp on the file gets set whenever you make changes with s-c-securitylevel. No aparently not ls -l returns the same informatiom both before and after doing changes with s-c-securitylevel as a normal user and returns the following :- [bentledr@bentledr policy]$ ls -l total 890 -rw-r--r-- 1 root root 904253 Aug 8 21:27 policy.20 and is labeled system_u:object_r:policy_config_t:s0 Is policycoreutils installed? Yes according to the following output. [root@bentledr ~]# rpm -qa policycoreutils policycoreutils-1.30.26-1 Note the time stamp on the file is as it was when I installed the system from the FC6 test 2 DVD and is just a few seconds eriler than the install.log in my root folder. *** Bug 171748 has been marked as a duplicate of this bug. *** If I attach a patch to this bug, can you apply it and respond with the results? Yes Created attachment 134848 [details]
verbose output patch
Please apply the attached patch, then run system-config-securitylevel from a
gnome-terminal/xterm/whatever so you can see what it prints out. Then provide
the output on this bug report. You may want to back up the files that will be
patched just in case we need to try something else later.
After having patched selinuxPaged.py as indicated and runnig s-c-securitylevel in a terminal window the output requested follows :- [root@bentledr ~]# system-config-securitylevel running modifiers.save booleanDirty is true running command: /usr/sbin/setsebool -P samba_enable_home_dirs=1 allow_execstack=1 allow_execmod=1 status of command is: 65280 output of command is: libsemanage.semanage_commit_sandbox: Could not remove previous backup /etc/selinux/targeted/modules/previous. Could not change policy booleans [root@bentledr ~]# NB system fully updated after being on holiday for the last week before doing the above now re-booting to see if the changes hvave stuck. The changes did not stick as expected from the output pasted above and the /etc/selinux/targeted/modules/previous folder has only an empty modules folder in it. Both the modules folder and its parent previous folder are time stamped as Wed 09 Aug 2006 07:08:31 PM BST. The previos foleder has the following permissions set system_u:object_r:semanage_store_t:s0 while the modules folder within has system_u:object_r:selinux_config_t:s0 and both have drwx------ access permissions as owner root and group root. Can you execute restorecon -R -v /etc/selinux SHould be ls -lZ /etc/selinux/targeted/modules/ drwx------ root root user_u:object_r:semanage_store_t active drwx------ root root user_u:object_r:semanage_store_t previous -rw-r--r-- root root system_u:object_r:semanage_read_lock_t semanage.read.LOCK -rw-r--r-- root root system_u:object_r:semanage_trans_lock_t semanage.trans.LOCK This took a lot longer to debug than it should have, so I am adding a message box to s-c-sl that will spit out the error message from setsebool, in case we ever run into another case like this. Having done as requested the permissions on the modules folder within the previous folder now match but are slightly different from your should be example see below ls -lZ /etc/selinux/targeted/modules/ drwx------ root root system_u:object_r:semanage_store_t active drwx------ root root system_u:object_r:semanage_store_t previous -rw-r--r-- root root system_u:object_r:semanage_read_lock_t semanage.read.LOCK -rw-r--r-- root root system_u:object_r:semanage_trans_lock_t semanage.trans.LOCK I will now see if changes stick following a re-boot. But one question remains was the modules folder within previous initially labeled incorrectly or did something else change it at a later date. Text output after running s-c-securitylevel now before re-booting for info. [root@bentledr ~]# system-config-securitylevel running modifiers.save booleanDirty is true running command: /usr/sbin/setsebool -P samba_enable_home_dirs=1 allow_execstack=1 allow_execmod=1 status of command is: 65280 output of command is: libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/netfilter_contexts to /etc/selinux/targeted/contexts/netfilter_contexts. libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/netfilter_contexts to /etc/selinux/targeted/contexts/netfilter_contexts. Could not change policy booleans The bad news is the changes made above still do not stick across a reboot. Presumably now as a result of the copy failing. Also note the previous folder is now missing. Trying the changes again then another reboot to see what happens. Text output after running s-c-securitylevel now before re-booting for info. system-config-securitylevel running modifiers.save booleanDirty is true running command: /usr/sbin/setsebool -P samba_enable_home_dirs=1 allow_execstack=1 allow_execmod=1 status of command is: 65280 output of command is: libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/netfilter_contexts to /etc/selinux/targeted/contexts/netfilter_contexts. libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/netfilter_contexts to /etc/selinux/targeted/contexts/netfilter_contexts. Could not change policy booleans Nothing appears to have changed so I expect changes will not have stuck. If they have I will give an update immediately. What version of policy are you running? This problem should have been fixed by a policy upgrade? Could you try setenforce 0 load_policy /usr/share/selinux/targeted/base.pp setenforce 1 /usr/sbin/setsebool -P samba_enable_home_dirs=1 [root@bentledr ~]# rpm -qa selinux* selinux-policy-2.3.9-5 selinux-policy-targeted-2.3.9-5 /etc/selinux/targeted/policy/policy.20 Below is the output from trying what you suggested. [root@bentledr ~]# setenforce 0 [root@bentledr ~]# load_policy /usr/share/selinux/targeted/base.pp load_policy: Warning! Policy file argument (/usr/share/selinux/targeted/base.pp) is no longer supported, installed policy is always loaded. Continuing... [root@bentledr ~]# setenforce 1 [root@bentledr ~]# /usr/sbin/setsebool -P samba_enable_home_dirs=1 libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/netfilter_contexts to /etc/selinux/targeted/contexts/netfilter_contexts. libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/netfilter_contexts to /etc/selinux/targeted/contexts/netfilter_contexts. Could not change policy booleans From the above output and seeing the tick in the box with s-c-securitylevel the change has taken for now. I will now reboot and se if it has stuck. As expected the change has not stuck I am sorry, My mistake setenforce 0 semodule -b /usr/share/selinux/targeted/base.pp setenforce 1 /usr/sbin/setsebool -P samba_enable_home_dirs=1 spoted this just prior to reading your last comment. base.pp in /etc/selinux/targeted/modules/active is 776270 bytes long with a modification date of 8/8/2006 (the original FC6TEST2 install date for this system) and the one in /usr/share/selinux/targeted is 7763319 bytes long with a modification date of 25/8/2006 (which is the date of the current package in rawhide) So it looks like the base.pp in /etc/selinux/targeted/active has not been updated. So doing as in comment #26 should fix things ??? I will update after doing it and rebooting. Doing as comment #26 stuck OK and for good measure some output captured from runninig s-c-securitylevel to prove things now work without errors. [root@bentledr ~]# system-config-securitylevel running modifiers.save booleanDirty is true running command: /usr/sbin/setsebool -P allow_execmod=1 status of command is: 0 output of command is: So it all works as it should do again. I will leave the patch in place as it has proved usefull in tracking this problem down. I look forward to seeing the updated s-c-sl with the debug feature as in comment #18. I'm going to close this one out since it seems to be solved for you. I've also just built a new s-c-sl into rawhide that should spit out error messages from setsebool. Hopefully you won't see that dialog any time soon, though. |