On Thu, Feb 6, 2014 at 12:13 PM, S. Dale Morrey <sdalemor...@gmail.com> wrote:
> My experience is that SELinux gets in the way far more than it helps. I'll
> be the first to admit I'm hardly a pro with the tool. However I do have
> some serious doubts as to the efficacy of a tool that blocks a daemon's
> behavior that was given explicity consent to start and run by root.
You *still* have doubts about that after you got hacked via a
privilege escalation exploit?! Come on.
The default Unix security model is a disaster. It is certainly better
than *no* security model, but that's not saying much.
[ details of your sad story of crazy uncle SELinux making your life
difficult elided ]
> The solution at that time was to disable SELinux, or at least tell it to
> allow this process to do whatever it wants. Thus if asterisk were to be
> compromised, SELinux would let it do whatever it wants. Which in my mind
> is the exact same thing as not having SELinux at all.
That was *your* solution at the time, not *the* solution. It was not a
very good solution from a security standpoint.
> A tool like SELinux really needs to be more intelligent. Adding a "study
> what this process does" mode and allowing it to learn the norms of the
> process would in my mind justify the hassle of going in and telling it
> "yeah sorry daemonX was supposed to be able to do that particular thing" on
> the rare occasion that a daemon does change behavior by design.
It does have a 'permissive' mode that logs access violations instead
of stopping them. There is also a tool called 'audit2allow' that will
examine the logs and then write allow rules to let it do those things.
I learned these things in the last 10 minutes with the help of
Google. The process is likely a bit more involved than this, but
surely not insurmountable to someone who can learn the somewhat
unfortunate dialplan configuration language of asterisk.
[ analogy with SSH and stopgap solutions elided ]
> As to your analogy about a house door, SELinux doesn't do anything of the
> sort. You're analogy would be more akin to SSH and passwords vs certs
> argument we've got going on in the other thread.
Let me make the analogy a bit more clear:
SELinux lets you put locks on privileges in a fine-grained manner.
You had some process that needed access to certain privileges; instead
of just giving it the keys to the ones it needed, you effectively left
all the doors unlocked to processes with UID 0 and gave that UID to an
exploitable process. If you'd locked all the doors and only given each
process the keys it needed, an exploit would only be able to disrupt
the resources that single process had the key to instead of your
entire machine.
Most programs written in C are, or will be after some future update,
exploitable via a stack-smashing attack. Most programs in Unix are
written in C. It follows that you really shouldn't let anything on a
public-facing server run UID 0 without some extra restrictions via
SELinux or something else if you value security at all.
> A better analogy would be along the lines of, "Do I really want to my
> paranoid schizophrenic uncle who is also really smart, but lives in the
> attic, tossing out my house guests each time they try to run upstairs to go
> to the bathroom?"
That's a colorful, if not very apt, analogy. But I will play along
and answer: Probably, yeah, if right next to the bathroom there's an
open door to a room with all your valuables laying out in plain sight
and the control panel to reconfigure your security system to lock you
out. You'd just use the intercom to buzz your uncle letting him know
that the person going up was someone you trust, and *lock the door to
the room of valuables*, for goodness sake.
I know security is not easy, but if you're going to have a
public-facing server, you really ought to take the time to figure it
out. You'll spend less time doing that than you will cleaning up
after you get hacked. And, as you just experienced, you *will* get
hacked if you continue to rely on the Unix security model.
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
