netdev - Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Apr 2016 16:07:43 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	David Miller <davem@...emloft.net>
Cc:	pabeni@...hat.com, linux-security-module@...r.kernel.org,
	James Morris <james.l.morris@...cle.com>, agruenba@...hat.com,
	Stephen Smalley <sds@...ho.nsa.gov>, fw@...len.de,
	netdev@...r.kernel.org, selinux@...ho.nsa.gov
Subject: Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed

On Wed, Apr 6, 2016 at 3:39 PM, David Miller <davem@...emloft.net> wrote:
> From: Paul Moore <paul@...l-moore.com>
> Date: Wed, 6 Apr 2016 14:36:43 -0400
>
>> On Wed, Apr 6, 2016 at 2:23 PM, David Miller <davem@...emloft.net> wrote:
>>> From: Paul Moore <paul@...l-moore.com>
>>> Date: Wed, 6 Apr 2016 10:07:27 -0400
>>>
>>>> "While marking the LSM hook structure doesn't directly affect the
>>>> SELinux netfilter hooks, once we remove the ability to deregister the
>>>> LSM hooks we will have no need to support deregistering netfilter
>>>> hooks and I expect we will drop that functionality as well to help
>>>> decrease the risk of tampering."
>>>
>>> This is not a reasonable postiion.
>>>
>>> The performance implications are non-trivial for using netfilter hooks
>>> when they aren't actually needed.
>>
>> With all due respect, I think you've taken what I consider to be some
>> unreasonable positions when it comes to the network stack and LSMs in
>> the past.  We have different perspectives and different priorities as
>> a result, from my perspective the security advantage gained by
>> eliminating the ability to disable SELinux at runtime is more
>> important.
>
> SELinux folks seem to get rather upset to people outright disabling
> the facility, but many users still do exactly that.

My opinion is that SELinux isn't for everyone; I think it would be
great if everyone enabled it, but I recognize that it isn't the best
fit for everyone's needs.  If users want to disable it in order to
better meet their needs, who am I to argue?

Or perhaps I should be upset?  I dunno, please tell me how I should
feel.  Like most people, I *love* when I'm told how I should react.

> In my opinion, it's uncompromising positions like the one you are
> having here is part of the reason that issue will continue.

Once again, I suspect this all a matter of perspective; from my point
of view the SELinux code has compromised quite a lot, especially in
the case of the networking controls.

> It is not AND, it's an OR, people want choice, and if you don't give
> it to them they will find a way to achieve what they want with or
> without your help.  And you might not like what they come up with.
>
> If distributions are turning SELinux on by default, then we have to
> care about whather netfilter performance should suffer for facilities
> which are unused.

I think you've made your point known, and I believe I've been clear
about the reasoning behind my decision as well.  I would suggest we
leave it at that until/unless someone has something constructive to
add to the conversation.

-- 
paul moore
www.paul-moore.com