Re: How to properly upgrade policy

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@xxxxxxxxxx
> http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>