[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