On Thu, Feb 6, 2014 at 2:22 PM, S. Dale Morrey <sdalemor...@gmail.com> wrote:
> Ok I understand what you are saying.
> My point is that SELinux gets in the way of what I would consider good
> security practices.
>
> Think about it this way.
> If you configure SELinux to be permissive, then there is effectively no
> difference between that and not having it run at all.
Well, you don't want to *leave* it running in a permissive mode. My
point was that doing so allows you to learn the set of privileges that
a process requires, which was at least a big part of what you were
asking for it to do for you.
And even if you do leave it in permissive mode, it could form a
component of an intrusion detection system.
> If someone breaks into ring 0 (uid 0 or whatever), then your system is
> hosed and it doesn't matter if SELinux is in place or not. Yes SELinux
> makes it harder to crack, but come on, we all know it doesn't make it
> impossible. In my mind it's like that little chain people put on their
> doors. Most of the time it's a pain and doesn't really serve the purpose
> it's touted to serve.
You seem to have entirely missed the point of SELinux.
In the plain Unix security model, a uid 0 process can do *anything*.
A compromise of any uid 0 process automatically compromises the
*entire machine*. And quite a few processes *need* to run at uid 0 to
do the things they need to do. One off-by-one error in one C file,
and ENTIRE NETWORKS OF MACHINES are completely vulnerable to anyone
who makes the discovery and decides to exploit it.
This is absolutely terrible from a security perspective.
Unacceptable, even. The fact that this seems normal and that you're
not grasping the difference between the standard Unix model and the
SELinux model suggests to me that you haven't really thought deeply
about *either* security model. You probably ought to take a step back
from this argument and do some deep thinking, if not a bunch of study
followed by deep thinking.
As a point of fact, most uid 0 programs only need a very limited
subset of the privileges of uid 0. In a properly configured SELinux
system, each uid 0 process is confined to exactly the set of
privileges it requires for operation. For most programs that run at
uid 0, this would change a compromise of that program from a
compromise of the ENTIRE MACHINE to a simple disruption of that ONE
SERVICE.
There are then *very few* points at which the entire system can be
compromised even if some uid 0 process is compromised. Yes, some of
those points may still exist, but successfully *reaching* those
vulnerable points would most likely require a kernel compromise.
Comparing the difference between the Unix model and the SELinux model
to a little door chain is hilariously, outrageously wrong.
[ description of fine security practices that were being followed elided ]
>
> Similar to Water Tight Doors in the Navy.
> Thus if any single box is compromised or even a handful of them, even a
> physical compromise where someone goes down to the noc and boots into
> runlevel 1, the wider purpose remains secure.
Um, this is *exactly* what SELinux does, but at the process level.
Why should a compromise of your SMTP server let an attacker write to
anything but mail spool files? Why are you letting attackers steal
your network and computing resources and spam people or launch attacks
with them, when you could have prevented it with a bit of
configuration?
> I believe that true security comes from a certain sense of paranoia. i.e.
> "What happens when this box falls into the hands of an attacker?" Not just
> "How do I secure this against attacks?". Note the difference in mindset.
> I go forward with assuredity in my mind that the box will eventually fall
> into someone elses hands. I never even question it. And while I would
> like to configure central auth because certificate managment is getting
> unwieldy, the fact is I don't because I assume at some point the auth
> server will get compromised.
The compromise of a process inevitably leading to the compromise of a
whole system is ridiculous. The fact that you don't question it is
really rather sad, but given the level to which "The Unix Way" is
ingrained it's not terribly surprising, I guess.
But your thinking here is flawed; given that any particular system
will inevitably fall into someone else's hands, there's *nowhere* to
put sensitive things. And if it makes sense to put security measures
*somewhere* (i.e., you believe that some security measures *can* be
effective), it makes sense to put them at the very surface of your
exposure, which allows you to prevent boxes from falling into the
hands of attackers in the first place.
> I guess the difference in mindset is summed up by the two narratives told
> by Levi and myself. He believes that a lock is there to secure valuables.
> I believe it's there to deter wouldbe attackers. That's a HUGE difference
> in thinking!
It was a silly metaphor that *you* came up with, I was just running
with it. And if you didn't believe that locks were there to secure
valuables, you wouldn't own a safe and put valuables in it.
Really, it's not about locks and keys, it's about the Principle of
Least Authority. Don't delegate authority that isn't required for the
task. This is what you're doing for security as well, but you are for
some reason *stopping* at a certain point and saying that the
principle is valueless beyond that point. That's nonsense.
I don't think SELinux is the best way to control the delegation of
privilege, but it's there, and people ought to either use it or find
something else that works in its place to restrict privileges of
processes to what they need.
[ contextually irrelevant personal anecdote elided ]
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
