|| ||"Jeff Spaleta" <jspaleta-AT-gmail.com>|
|| ||"Development discussions related to Fedora" <fedora-devel-list-AT-redhat.com>|
|| ||Re: More PATH fallout. Who decided this was a good idea?|
|| ||Sat, 6 Dec 2008 10:29:18 -0900|
2008/12/6 Callum Lerwick <email@example.com>:
> Which is why we don't do all this work, because it is indeed stupid and
> pointless, and we just chmod 755 /usr/sbin/user* and be done with it.
> Relying purely on userspace to enforce security is fundamentally broken.
> Face it, Fedora is never going to be certified. Why then would people
> pay for RHEL. ;D
But other fedora derived spins may. Is there need for certified
'appliance' situations that a new 3rd party could leverage Fedora to
create? I can imagine all sorts of no network software appliance
situations where the CAPP certification applies and a Fedora derived
image would be a good development target.
CAPP certiafiability is just another desired feature which may or may
not be compatible with other desired features. The question for me is,
can CAPP certification it be implemented in a modular fashion or does
it have to be integrated by impacting traditional defaults.
I think CAPP certification, as I understand it, is a poor fit for the
security needs of our default Fedora offerings, where we expect an
active network. That could be part of the problem. CAPP certification
certainly feels like the wrong capability to try to target in our
default usage case. Our default usage scenario for the supported spins
is simply not the usage that CAPP tries to handle. But it could be
very useful for a new spin concept which targets exactly the usage
case the CAPP speak to.
fedora-devel-list mailing list
to post comments)