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