On Tue, Jan 3, 2012 at 12:41 AM, Bennett Haselton <bennett@xxxxxxxxxxxxx> wrote:
>> Standard/non-standard isn't the point. The point is to control what an
>> app can do even if some unexpected flaw lets it execute arbitrary
>> code.
> What's the scenario where this port restriction would make a
> difference? Suppose an attacker does find a way to make squid execute
> arbitrary code. Then if part of their plan is to make squid start
> listening on a second port in addition the one it's already using (3128,
> the default), they could just make it listen on another port like 8080
> which is permitted by SELinux.
You are thinking the wrong direction. No one can anticipate every
possibility that someone might do to take advantage of
vulnerabilities. Instead think in terms of the minimum the
application should be allowed to do under any circumstance. Then
you'll also have firewalls blocking every port except where you know
your own application is listening anyway.
>>> In other words, when SELinux causes a problem, it can take hours or days
>>> to find out that SELinux is the cause
>> Errr, no - all you have to do is disable SELinux and see if the
>> behavior changes. On your test machine where you should be testing
>> changes, this shouldn't be a big risk.
> Well I meant, if you didn't happen to know enough about SELinux to
> realize that it was the cause of many non-standard system behaviors. If
> you knew about SELinux as one of those things that frequently gets in
> the way, then you'd probably think of it a lot faster :)
Well, the other security rules for linux/unix are trivial, so SELinux
should pop to mind immediately for surprising behavior, especially if
you have changed configurations from the expected defaults.
> One could easily say, "Hey, you should just know about SELinux", but the
> problem is that there can be dozens of things on a machine that could
> potentially cause failures (without giving a useful error message), and
> each additional thing that you "should just know about", decreases the
> chances that any one person would actually know to check them all, if
> they're not a professional admin.
OK, the point here is that you have some unknown vulnerability that
the stock linux security mechanisms aren't handling. I'm more
inclined to think it is a software bug rather than brute-forcing a
password, but that's speculation. So, which do you think will be more
difficult - tracking down some unknown bug in millions of lines of
code with no real evidence, or adding another layer of security that
is mostly pre-configured in the distro anyway?
> Again, you don't have to take my word for it -- in the first 10 Google
> hits of pages with people posting about the problem I ran into, none of
> the people helping them, thought to suggest SELinux as the cause of the
> problem.
Most distributions don't include SELinux, so don't expect to find it
always mentioned in random googling.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
