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

Les Mikesell lesmikesell at gmail.com
Tue Jan 3 03:48:22 UTC 2012


On Mon, Jan 2, 2012 at 8:30 PM, Bennett Haselton <bennett at peacefire.org> 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.

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

-- and even then you're not done,
> because you have to figure out a workaround if you want to fix the
> problem while keeping SELinux turned on.

You do have  a point there.

-- 
  Les Mikesell
     lesmikesell at gmail.com



More information about the CentOS mailing list