Re: an actual hacked machine, in a preserved state

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



On 1/2/2012 7:48 PM, Les Mikesell wrote:
> On Mon, Jan 2, 2012 at 8:30 PM, Bennett Haselton<bennett@xxxxxxxxxxxxx>  wrote:
>
>>    What apps are those (i.e. the ones that
>>> SELinux would have broken) and if they are open source, have those
>>> projects updated the app or the underlying language(s)/libraries since
>>> you have?
>> So here's a perfect example.  I installed squid on one machine and
>> changed it to listen to a non-standard port instead of 3128.  It turns
>> out that SELinux blocks this.  (Which I still don't see the reasoning
>> behind.  Why would it be any less secure to run a service on a
>> non-standard port?
> 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.
>> But here's the real problem.  Since I didn't know it was caused by
>> SELinux, all the cache.log file said was:
> Things blocked by SELinux show up in audit.log.  I agree that the
> SELinux implementation is confusing, but it does give more control
> over what apps are allowed to do.
>
>> 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 :)

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.

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.  (By contrast, when iptables causes a problem, people usually 
figure out that's what's going on.)

Bennett
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[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