Expectation Management for Test Releases

[Gene C.]

On Tuesday 20 April 2004 23:28, Jeremy Katz wrote:
> On Tue, 2004-04-20 at 18:01, Gene C. wrote:
> > So, my question:  For FC2 final (and really Test3 also), should those of
> > us interested in selinux and willing to put up with some problem continue
> > to install it enabled?  If policy is going to be redesigned, is this
> > worth the effort.  Naturally, any bugs found in FC2T3 would be reported
> > but I am not sure anyone will have time to address them.  Furthermore, if
> > the plan is to redesign things post FC2 (planned for FC3 I assume),
> > little attention will be given to bugs in this old mechanism.
>
> Yes, we very much strongly encourage those who are very interested in
> SELinux and comfortable enough to work with it to continue installing
> with it enabled and in enforcing mode as well as continue to help us
> work out the problems as they're discovered.  That's why we're leaving
> the possibility of enabling it there.  

OK, I will continue installing enforcing although I may hedge my bets and do 
some testing with selinux disabled also (to make sure all applications I 
really need to work do work).

I just wanted to make sure that any new problems involving policy in with 
FC2T3 or FC2-final will at least be looked at ... no use testing this stuff 
if problems will be ignored.

>
> It's just that it's not ready for the masses to consume yet, and in
> doing so, we'd just end up with a Fedora Core release that was less
> stable and with many apparent bugs due to SELinux.  We'll probably go
> through this again with FC3 where I plan to return things to enforcing
> by default in the development tree very soon after the release of FC2.

Yes, it does not help either Fedora or SELinux to get a "bad name" because 
there was not enough time left to get everything working.

>
> As far as redesign of policy, there's discussion around developing a
> less strict policy, ie, one that allows users in general to do things
> but takes the approach of locking down specific services.  But the hope
> is to do this in such a way that you can trivially switch back and forth
> between the policies with a simple toggle and thus any testing on the
> stricter policy we have now will still be quite useful.  Think of it
> along the lines of the old Medium vs High firewall distinction.

Mmm ... In Jeff Johnson's message 
http://www.redhat.com/archives/fedora-selinux-list/2004-April/msg00268.html
he implies there there will be some redesign of how policy is implemented 
("the entire mechanism is gonna be scrapped and redone") ... at least that is 
my understanding of what he said.  The current situation with a single policy 
package (resulting in policy and policy-sources runtime packages) which 
covers everything does not address packages outside of Fedora Core very well.  
If an Extra or 3rd party package adds some policy definitions (to 
policy-courses files), does the policy get rebuilt by the Extra/3rd-party 
package?  This would require every system to include policy-sources and the 
other packages necessary to rebuild the policy from source rules.

It is this "redesign" that I was wondering about.  Will enough attention be 
paid to problems with the existing policy ... will there be sufficient time 
available to allow developers the time to do any redesign if they need to 
look at fixing problems?  Or, will existing problems be ignored in the 
interest of working on the redesign?

This is NOT intended as a flame of any kind but the track record of addressing 
existing problems is not good.  My own experience (on FC1) with gnome-panel 
(draw problem) and gftp is that with upstream fixes available, official 
packages took far too long to be reasonable (See discussions about old bugs 
on the fedora-devel-list).  If selinux/policy bug reports will be addressed 
(not necessarily solved), then I will continue trying to work with 
enforcing=1.  However, I do worry about the commitment to addressing bugs 
versus redesigning things.  I am an engineer and can certainly understand 
that it can be much more fun to work on a new design which just does not have 
the problems of a current implementation rather than fixing problems in the 
current implementation.
-- 
Gene