not installing SELinux with Fedora
stewartetcie at canada.com
stewartetcie at canada.com
Thu Jun 23 18:58:16 UTC 2005
On Sunday, 2005-06-19 at 16:08 (PDT)
Steve G <linux_4ever at yahoo.com> wrote:
>Its very easy to do, but you will be running your own
>distro. :) Just get a RH9 build host and use the
>rookery build system. It'll let you know which
>packages need TLC.
Beware of forks masquerading as subsystems. The offer
of mandatory access control is seductive, but the
SELinux implementation is flawed if it amounts to a
fork in the Linux code base.
>SE Linux does need some help in managing policy.
>This what's missing from SE Linux.
>A good configuration for the non-security expert.
If that were the only problem, it would be enough to
preclude the inclusion of SELinux from a general
purpose Linux distribution until such time as good
management tools are available.
On Monday, 2005-06-20 at 07:10 (PDT)
Stephen Smalley <sds at tycho.nsa.gov> wrote:
>Most distributions don't want to have to ship
>multiple variations of the kernel and userland, so
>they naturally don't want to have ship a SELinux and
>non-SELinux variant of kernel, coreutils, etc.
Yikes, I should have anticipated this, given the forum
and the topic, but, in the immortal words of Monte
Python, "No-one ever expects the Spanish inquisition!"
Let's be clear about one thing. I am neither a devil,
nor am I a devil's advocate and I really can't find the
time right now for an extended vacation at a U.S.
resort in Cuba, or even an unscheduled layover in
Syria. I know you guys listen to everything, all the
time, everywhere, but when my girl friend said, "Oh,
you devil," that was just a figure of speech. Really.
Now, let's approach the topic under discussion one step
at a time, as a Jesuit would.
Connecting to the internet can be risky, because we
don't know who else has an internet connection, or what
malicious plans they may have. So intellectual property
developers often disconnect clusters used as render
farms for movie production, or compile farms used for
code production, from external networks. This is as
appropriate for protecting open source products from
damage as it is for protecting proprietary products
from theft. In fact, many private nets don't connect to
the internet. SWIFT, the Society for Worldwide
Interchange and Funds Transfer, is a case in point.
Isolation provides strong security and we're not likely
to stop doing it anytime soon, but it is inappropriate
for all cases. That's why we use multi-homed firewalls
to interconnect the internet to a DMZ for the servers
that provide internet services and to the internal
firewalls that protect local area networks. This works
pretty well, even better since IP Tables came along,
and the proof is that most of the systems compromised
by intruders either lack such protection, or don't have
it configured properly.
Wouldn't it be nice to have a general purpose operating
system that could be pruned and tuned for optimal
performance on isolated systems, firewalls, servers,
workstations, or laptops for road warriors? Oh, and it
must be open source, because we can't validate system
security unless we can audit the code. Certification
requires certainty. A number of operating systems meet
One candidate is Linux (a. k. a. non-SELinux). If I
have to roll my own distro from Fedora in order to
optimize performance by removing unnecessary
subsystems, such as mandatory access control on an
isolated system, then Fedora is no longer a general
purpose system and it is no longer Linux, now it is
These comments are offered in the spirit of
constructive criticism. I'm grateful you declared your
bias, for your spirited defence of your product and
very grateful SELinux was contributed to the open
source community, warts and all. However, SELinux isn't
the only possible implementation of mandatory access
control for Linux (cf. sHype). If my criticicms are
valid, SELinux must either be improved, or it'll be
replaced by a better implementation. Perhaps I'm wrong.
Time will tell. Meanwhile, thanks for listening.
More information about the fedora-selinux-list