Bug 202375 - Changes made to security policy lost after reboot
Summary: Changes made to security policy lost after reboot
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-securitylevel
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Chris Lumens
QA Contact:
URL:
Whiteboard:
: 171748 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-13 21:39 UTC by David Bentley
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-29 16:02:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
verbose output patch (1.16 KB, patch)
2006-08-24 19:27 UTC, Chris Lumens
no flags Details | Diff

Description David Bentley 2006-08-13 21:39:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060808 Fedora/1.5.0.6-3 Firefox/1.5.0.6 pango-text

Description of problem:
Changes made are applied as expected on closure of the tool but on the next reboot they have all been lost.

Version-Release number of selected component (if applicable):
system-config-securitylevel-1.6.23-1

How reproducible:
Always


Steps to Reproduce:
Make a change to allow samba to share home directories and to enable and in memory protection allow text relocation and executable stack for instance and the changes happen as expected on exit but on next reboot they have been lost.

The above was done as a normal user after giving the root password.

Actual Results:
See above

Expected Results:
Changes to stick across a reboot

Additional info:

Comment 1 Chris Lumens 2006-08-14 21:00:26 UTC
What type of policy are you using - strict or targeted?  What are the contents
of /etc/selinux/<policy type>/modules/active/booleans.local?

Comment 2 David Bentley 2006-08-14 21:58:46 UTC
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.

Comment 3 David Bentley 2006-08-14 22:22:21 UTC
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

Comment 4 Chris Lumens 2006-08-15 02:41:38 UTC
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.

Comment 5 Daniel Walsh 2006-08-15 11:50:42 UTC
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.



Comment 6 Chris Lumens 2006-08-15 15:29:25 UTC
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.

Comment 7 David Bentley 2006-08-15 18:29:46 UTC
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 


Comment 8 Chris Lumens 2006-08-15 18:57:45 UTC
Is policycoreutils installed?

Comment 9 David Bentley 2006-08-15 19:11:44 UTC
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.

Comment 10 Chris Lumens 2006-08-16 14:55:36 UTC
*** Bug 171748 has been marked as a duplicate of this bug. ***

Comment 11 Chris Lumens 2006-08-22 18:00:41 UTC
If I attach a patch to this bug, can you apply it and respond with the results?

Comment 12 Daniel Walsh 2006-08-22 18:58:44 UTC
Yes


Comment 13 Chris Lumens 2006-08-24 19:27:17 UTC
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.

Comment 14 David Bentley 2006-08-26 15:02:52 UTC
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 ~]# 

Comment 15 David Bentley 2006-08-26 15:04:34 UTC
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.

Comment 16 David Bentley 2006-08-26 17:15:22 UTC
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.

Comment 17 Daniel Walsh 2006-08-28 13:58:44 UTC
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


Comment 18 Chris Lumens 2006-08-28 15:17:21 UTC
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.

Comment 19 David Bentley 2006-08-28 17:54:09 UTC
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.

Comment 20 David Bentley 2006-08-28 17:59:26 UTC
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

Comment 21 David Bentley 2006-08-28 18:14:58 UTC
The bad news is the changes made above still do not stick across a reboot.

Presumably now as a result of the copy failing.

Comment 22 David Bentley 2006-08-28 18:24:25 UTC
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.

Comment 23 Daniel Walsh 2006-08-28 19:41:16 UTC
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

Comment 24 David Bentley 2006-08-28 20:06:11 UTC
[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.

Comment 25 David Bentley 2006-08-28 20:13:09 UTC
As expected the change has not stuck

Comment 26 Daniel Walsh 2006-08-28 20:41:49 UTC
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

Comment 27 David Bentley 2006-08-28 20:48:07 UTC
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.

Comment 28 David Bentley 2006-08-28 21:07:04 UTC
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.

Comment 29 Chris Lumens 2006-08-29 16:02:02 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.