On Tue, Mar 09, 2004 at 03:21:34AM +1100, Russell Coker wrote:
On Tue, 9 Mar 2004 03:06, Paul Nasrat <pauln(a)truemesh.com>
wrote:
> On Mon, Mar 08, 2004 at 11:07:43AM -0500, Bill Nottingham wrote:
> > Tom Mitchell (mitch48(a)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