[CentOS] an actual hacked machine, in a preserved state

[Bennett Haselton]

On 1/2/2012 11:04 PM, Les Mikesell wrote:
> On Tue, Jan 3, 2012 at 12:41 AM, Bennett Haselton<bennett at peacefire.org>  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.

I agree about minimum permissions, but my argument here is that 
permitting squid to "listen" on any arbitrary port it wants is just as 
"minimum", in terms of security implications, as permitting it to 
"listen" on port 3128.  Either way, once the attacker has connected to 
it, the scenarios are identical from that point on (either the attacker 
knows an exploit to take control of squid, or they don't; either the 
squid process runs with sufficiently high privileges that the exploit 
can be used to do damage, or it can't).

>>>> 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?

Well I'm trying to weigh the costs of using it -- with all of the silent 
failures for operations that have no security implications -- against 
the reduced risks.  If many exploits against httpd, for example, could 
have been prevented by SELinux, that may make it worth it.  (And of 
course the suggestions about how to diagnose problems caused by SELinux 
are helpful.)

Bennett