Installing new policy?

[Tom Mitchell]

On Tue, Mar 09, 2004 at 03:21:34AM +1100, Russell Coker wrote:
> On Tue, 9 Mar 2004 03:06, Paul Nasrat <pauln at truemesh.com> wrote:
> > On Mon, Mar 08, 2004 at 11:07:43AM -0500, Bill Nottingham wrote:
> > > Tom Mitchell (mitch48 at sbcglobal.net) said:
> > > > If I understand this...
> > > >
> > > > In development cycles having the "current" best practice policy does
> > > > make sense for some,  but not outside the context of "default policy
> > > > development".
> > >
> > > Yes, but if you're pushing new policy that actually fixes bugs
> > > (think post-release here), you'd want that automatically installed
> > > on upgrade.
> >
> > I believe Jeff was working on this, however the hooks would have to be in
> > rpm I imagine as you probably don't want rpm_script_t having write access
> > to policy_src_t right?
> 
> At the moment rpm_script_t has access to so much that there's no point in 
> trying to impose any serious restriction on it.
> 
> I suspect that limiting rpm_script_t in any significant way will have to wait 
> until we have multiple domains for rpm for installing packages with different 
> signatures.

Are there thoughts for design changes to rpm.  Hooks where the
trust/level of rpm changes when packages are unsigned, when rpm is
going to install or update digital signatures or updates to rpm
itself.  Some interesting flags...  
	 rpm --nosignature --nopreun --nopostun 
At what level do scriptlets run.

For now what are the tactical thoughts on updating policy during
development.  Is it as simple as kernel (/usr/src/linux*) where the
top level dir famous name is a link to a versioned dir or will
rpmnew/rpmsave be the norm.  Since "rpm" is not universal what
strategy has a chance of working with or without rpm so higher level
SELinux documentation will get the right thing to happen.

Do/should tools like up2date and yum have standard exclusion rules (like
kernel*) that will keep the old and the new side by side for
comparison.

   cd /etc/security/selinux/src
   diff -d policy policy.previous	# stop look and listen.
   cd /etc/security/selinux/src/policy  # policy could be a symlink to policy.newest
   make
   make relabel

If you're pushing new policy that actually fixes bugs will it break site policy?
I would be unhappy if my co-lo box had this line changed. ;-)
   # uncomment to allow ssh logins as sysadm_r:sysadm_t
   define(`ssh_sysadm_login')
 

-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.
	mitch48-at-sbcglobal-dot-net