Request for Trademark Approval (Fedora AOS Spin)

[Karsten 'quaid' Wade]

On Fri, 2008-08-29 at 02:09 +0200, Jeroen van Meeuwen wrote:
> A little clarification on the disabling of SELinux and so forth;
> 
> the maximum an AOS can do to form a viable basis for all kinds of weird 
> appliance stuff to be built upon is to set SELinux to permissive. You 
> won't see many appliances out there actually having SELinux enforcing 
> (or actually having SELinux at all). 

Why is that?  Not perhaps because the first thing they do is turn
SELinux off and don't bother trying to get their application to run
under a custom policy?

> It'll most likely not be very 
> sustainable for appliance builders to move their work into something 
> that can cope with the SELinux culprit. This is a side-note as to why it 
> is not unreasonable to disable SELinux on this particular spin.

I don't understand why they cannot write policy for their own
application?  Even if it's a hacky audit2allow-created policy.

The reasons are two-fold:

* A system running under SELinux with a hacky policy is much more secure
while still allowing the application to do whatever it wants; the
developers don't have to fix their methods to be more secure; and the
app is no worse off than without SELinux while the system is better.

* If they do not get the kickstart with SELinux enabled, how are they
ever going to try and know if it needs custom policy?

In the last case, they actually get a chance to improve the security in
their application.

> On the other hand, of course we do have an agenda to push and that 
> agenda includes SELinux as being one of the core features of the entire 
> Fedora line of products (including the few enterprise linux spin-offs). 
> It's one of the main features and we would rather see appliances built 
> upon an AOS that has SELinux enforcing by default while it can still be 
> disabled.
> 
> Whether we consider SELinux to be a main feature that has to be included 
> (enforcing) on every spin impacts our ability to really do the 
> customization that we find important, too. I'm thinking that a security 
> / forensics spin (extended rescue environment on live media) will not 
> want to have SELinux do anything either (especially not restorecon), and 
> will maybe have to set it to permissive.

What about just not installing policycoreutils?  I don't think SELinux
requires it, and of course it can be installed later.  I think that is
in fact one of the reasons for having the coreutils for policy writing
in a separate package, because the system should be able to run SELinux
without potentially dangerous policy generation tools being available.
(The policy written on a safe machine then deployed to the locked
environment.)

I'm just saying ... I would consider it _very_ seriously and for a
_long_ time before we removed SELinux from the must-have list.  IMHO et
al.

- Karsten
-- 
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20080828/5c948371/attachment.sig>