How to properly upgrade policy

Daniel J Walsh dwalsh at redhat.com
Fri Jun 25 15:28:16 UTC 2004


Bob Gustafson wrote:

>On  Fri, 25 Jun 2004 06:17:34 -0400, Dan Walsh wrote:
>  
>
>>Ivan Gyurdiev wrote:
>>
>>    
>>
>>>On Thu, 2004-06-24 at 16:45 -0400, Stephen Smalley wrote:
>>>
>>>
>>>      
>>>
>>>>On Thu, 2004-06-24 at 16:21, Ivan Gyurdiev wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>What's the proper way to upgrade the selinux policy?
>>>>>
>>>>>yum and rpm leave me with .rpmnew files every single time.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>This suggests that you installed the policy source package as well, or
>>>>locally modified your policy directly.  If you install or update the
>>>>policy source package (selinux-policy-strict-sources), then it should
>>>>rebuild the policy files from source and load the new ones automatically
>>>>as part of the %post.  Updating the policy package
>>>>(selinux-policy-strict) will then leave you with .rpmnew files because
>>>>it sees that the files have been locally rebuilt.
>>>>
>>>>
>>>>        
>>>>
>>>Yes, I have the sources package instaled - I need it to make relabel
>>>don't I? Since I upgrade through yum, and rawhide updates the sources
>>>package with the other one, I always update them together. However, the
>>>resulting files are not the same - file_contexts and file_contexts.
>>>rpmnew are different, and the binary policy differs too.
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>>Do I need to run make relabel?
>>>>>
>>>>>______________________________________________________________________
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>It is generally safest to do so, but often unnecessary (only if there is
>>>>a relevant change to file_contexts that affects you).  Relabeling is not
>>>>presently automatically performed upon a policy update.
>>>>
>>>>
>>>>        
>>>>
>>>Are there plans to change that?
>>>
>>>
>>>
>>>
>>>      
>>>
>>No because this could be a very long process.   We are hoping to not
>>change policy very often and less often change File Contexts.
>>Especially with Targeted policy.  I have modified fixfiles to be able to
>>use RPM files as input and we are looking into a cron script to walk the
>>file system on a regular basis to inform users of problems in the file
>>context.  This script could either repair the problems automatically
>>(Not recommended), or easily allow the administrator to fix them the
>>next morning.
>>
>>Setfiles and restorecon have a new qualifier (-o filename) which will
>>record the file paths of any files that the tools find with the
>>incorrect security context.  So if you run setfiles -n -v -o
>>/tmp/badfilecontexts, you would have a report and a file with all the
>>paths of files with bad file contexts.  If everything looks ok, you
>>could run restorecon -f /tmp/badfilecontexts and clean them up quickly.
>>
>>Dan
>>
>>    
>>
>
>Sounds pretty good in the long term.
>
>However, looking my output from fixfiles, it seems as though there are
>gross changes in policy that are occasionally occuring during this
>development phase (object_r -> system_r).
>
>It would be nice to get some sort of indication that a fixfiles run would
>be helpful when these gross changes occur.
>
>----
>There was a note awhile ago saying that the log from fixfiles would remain
>in the /tmp area, even though 'Y' was chosen to zap the /tmp files prior to
>relabel. Does this file survive the necessary following reboot? (I did not
>see it when I looked just now).
>  
>
Log files are stored in /var/tmp to avoid the conflict.  They should 
survive the reboot.

>----
>There was some talk of changing PAM so that it would better handle the 'su'
>operation. Has this been done?  I ask this because I cannot get into any of
>my root priviledged Gnome applications anymore. This had been a problem,
>then it was fixed, now it is a problem (for me) again.
>
>  
>
We moved around the pam_xauth and pam_selinux open calls in 
/etc/pam.d/su  (coreutils)

>It seemed as though the proposed PAM change would also enable a shutdown
>direct from Gnome - even though Gnome had originally been started up as a
>user application (it would of course ask for a root password).
>
>-----
>I am currently (as of an hour ago) current on 'yum update' and I did a
>complete 'fixfiles relabel' at init 1 state before my last boot.
>
>BobG
>--
>fedora-selinux-list mailing list
>fedora-selinux-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>




More information about the fedora-selinux-list mailing list