selinux stuff - I just don't get -- broad arguments = yet another meta-discussion (YAMD)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Peter Farrow <peter@xxxxxxxxxxx> wrote:
> Thats because its entirely possible to make a system secure
> without Selinux, it was only born in Centos from Version 4.

There is _no_ possible way to make a system secure _except_
for yanking the plug.  Furthermore, anytime you offer
networking services, you open up holes in the system.

> While I would never recommend turning off a firewall,

This is far too broad of a statement.

First off, "firewalls" can actually not only be a _false_
sense of security, but they are quite _indifferent_ at times.
 Most people assume firewalls must be turned on because many
platforms have so many services that _always_ run,
_regardless_ of configuration.  That is a leftover from the
Windows world.

A UNIX/Linux system with select networking services that are
known to be running and accepting all packets from any source
IP benefit virtually _little_ from source address packet
inspection (let alone TCP Wrappers becomes useless).  At that
point, you're talking more about intrusion detection than
anything.  And that's typically at layer 5+.  The new focus
is on IDS/IPS at layer 7 in today's world of unifying HTTP
services.

The overwhelming majority of firewalls only address layer-3/4
security, layer-2 if you're lucky, but virtually _never_
layer 5+.

> I would recommend turning off Selinux:

I would recommend _against_ that.

That's _exactly_ saying that you don't need different user
logins if you have groups defined, because you've entrusted
people in a group of the same access.  You're ignoring many,
many things accountability-wise.

> a firewall doesn't stop stuff on the box working properly

Of course not because it only deals with (largely) blocking
layer-3/4 communcation.  It does absolutely nothing to deal
with layer-5+ exploits -- let alone local issues.

> as it ships, Selinux does.

Of course!  Anytime you implement RBAC/MAC, you're going to
break things.  But the answer is _not_ to merely turn it off,
it's to write the software to work with RBAC/MAC.

Like it or not, Linux software is going to have to "grow up"
and face the RBAC/MAC music.  In addition to software, that
requires administrators learning to deal with it.

To do less is to leave Linux _well_behind_ other OSes in the
Common Criteria certifications -- certifications that _do_
exist for damn good reasons.  
 
> For example anything that would stop squid running properly
> out of the box (as Selinux does) is of limited value,

Value to whom?
The person who is trying to secure the server?
Or someone who just wants Squid to work?

REALITY:

SELinux is no different than any other security mechanism, or
any other troubleshooting.  If something doesn't work, you
turn off all sorts of constraints.  If it starts working
suddenly because you turned something off, that doesn't
necessarily mean whatever you turned off is the "problem,"
but that its current configuration prevents something from
working.

You can either choose to find out why, or you can turn it
off.  But make no mistake, SELinux is _not_ just "going away"
because people don't want to deal with it.  Just like NPTL,
just like ANSI C++ compliance before that and just like GLibC
2 before that.  I have continually agreed with Red Hat's
insistence on certain technologies because without them,
Linux is seriously _not_ moving forward.

Heck, look at Windows!  99.9% of Windows applications won't
run with the full NT security model enabled.  In the Linux
world, you start enforcing the full security of the OS, and
the applications fall in-line.  SELinux is just another set
of hurdles to overcome in Linux -- things that _other_ UNIX
flavors _have_.

Linux needs to join them or people like myself _will_ be
running Solaris on our next server purchase (there is already
the filesystem argument I've blabbed about prior, with
RBAC/MAC being an increasing consideration. ;-)

> in this instance its not required,

"Not required" in what context?
That's the problem.

> it gets in the way, it IS easily possible to have
> a secure system without Selinux, whereas that is doubtful
> without a firewall.  

I _disagree_ entirely, and that is an overly broad statement.
One might argue that a layer-3/4 packet inspector is rather
"false security" when it comes to a layer-7 proxy service. 
;->

Now SELinux is not a layer-7 packet inspector.  But it _does_
prevent applications from accessing parts of the system that
should not be allowed to access.  It's not perfect and God
knows Red Hat begs for new rules everyday to deal with
things, but the headaches don't stop _until_ people start
getting serious about putting SELinux in the fore-front of
their considerations.

> Chalk and cheese springs to mind.
> If Selinux is the "baby" in your metaphor, then the best
> thing to with it is hold it under the water until it stops
> moving....

No offense, but Solaris continues to gain back Linux
mindshare for this, and other reasons.  No, it's not
GPL-like, but it's MPL-like.  If SELinux isn't adopted, Red
Hat _knows_ it's going to be a serious mark against Solaris.

> For those of us who know how to configure secure systems
> (and I'm not suggesting you don't Tony by any stretch)
> Selinux is additionaly bloat I (we) don't really need.

Fine for you'all.  But I do want and need SELinux.

Yes, I disable it on some systems.  But at other times, I've
caught a few things that should not access things.

> It just slows the system down...
> I''ve never needed it......

But lack of SELinux adoption will slow Linux down.  Red Hat
knows this.


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux