On 08/12/10 04:28, Les Mikesell wrote:
> On 12/7/10 8:28 PM, Marko Vojinovic wrote:
>>
>>> I think you've missed the point that 'all that stuff' (being traditional
>>> unix security mechanisms) are not all that insecure. It is only when you
>>> get them wrong that you need to fall back on selinux as a safety net.
>>> And if you can't get the simple version right, how can you hope to do it
>>> right with something wildly more complicated?
>>
>> My comment was ironic --- the point is that if you decide you don't need one
>> security layer, why don't you decide that you actually don't need another, and
>> another, and... all of them?
>
> Well, one reason might be that you've used those other standards-ratified layers
> for decades and the only problems you've ever had were caused by stupid
> programming. So you don't expect adding another layer of programming that isn't
> standardized across platforms to solve all your problems.
Ehm ... is iptables a ratified standard across platforms? SELinux is
basically a kind of iptables, but oriented against restricting
file/network call/system call/process/etc accesses locally on the box.
>> Disabling SELinux is the same type of decision as disabling the firewall ---
>> it's there to protect you, yet you don't know how to properly configure it and
>> use it, furthermore you don't want to bother to learn, so you simply disable
>> the thing that's getting in your way and preventing you from doing what you
>> want (which is typically very stupid securitywise, but ignorant don't care
>> anyway...).
>
> Or you might use a hardware firewall platform so you don't have to deal with all
> the bizarrely different ways every system you touch handles software firewalling.
You still need to learn how to use that hardware firewall, though.
>> And I could argue that iptables configuration is at least equally complex as
>> SELinux configuration.
>
> Agreed, and something that equally needs standardization.
iptables is a de-facto standard on all Linux distributions nowadays. It
is not ratified by ISO, IETF or similar ... but how does that make the
real life scenario any different? That's just a piece of paper.
iptables works, and so does SELinux - when you learn how to use it.
>> So I would expect the admin who disables SELinux by default to also disable
>> the firewall by default --- they both get in your way, especially if you use
>> some 3rd party software that requires both of them to be custom-configured.
>
> No, I would expect the admin who disables SELinux to be managing thousands of
> machines, many different OS versions, with programs from hundreds of sources
> running on them, with those hundreds of software sources not catering to the
> non-standard needs of one particular platform.
SELinux is another layer of security. It's not the only security layer.
If an admin decides to disable SELinux due to having too much to manage
already, that's that admins choice. However, it is still not
recommendable to trade security for simplicity.
>> But I don't see anyone suggesting that disabling the firewall would be a good
>> idea, so why disable SELinux then? Once you go down the "I don't need this
>> security layer" road, where do you stop, and why?
>
> Anyone who started before SELinux was around is probably quite comfortable
> without it. And perhaps the same for iptables or software/host based firewalls,
> though not firewalling in general.
SELinux came as a result that someone found weaknesses and wanted to try
avoid security issues. Just like when firewalls began to become so
popular 20-30 years ago or so. There was a need to improve something,
and someone did the job. Nobody cared much about firewalls in the early
80's. Why? Maybe because nobody thought anyone would abuse or misuse
the network infrastructure?
SELinux has been around for about a decade or so. And I believe that
the more widespread SELinux becomes, and the more users it gets, the
more people will not understand such discussions like this.
I remember in the early days when I found ipfwadm difficult, but I
tackled it in the end. Then ipchains came, and the same round again.
Then iptables came, which was easier due to the similarity to ipchains.
Nowadays, I don't have any issues with iptables at all, and find it
like a breeze to play with. And there's probably plenty of similar
things - configuring MySQL and PostgreSQL, setting up Apache securely,
DNS/BIND configurations. You start from scratch, and begin to learn.
I remember I found SELinux tricky and difficult. Then I learnt more
about it, and guess what - it's no magic for me any more. It's actually
fairly simple to use for me. And I'm no SELinux developer. But I'm
happily running SELinux on about all of the 12-15 boxes which is under
my control. Yes, AVC's happens ... but I've learnt how to read them and
understand them, then I understand what is happening and know what I can
do about it ... just as I had to do the same when looking at
iptables/ipchains LOG entries. In the beginning, it was less
understandable - now I barely understand I struggled with it in the
beginning.
But unless you *invest time* to learn the tools ... you'll only be
frustrated that something doesn't work. And some people find it easier
to give up and just disable it ... just like some people even did with
firewalling in the early days.
kind regards,
David Sommerseth
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
