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]

Message-Id: <20160406.153955.2244652846180310527.davem@davemloft.net>
Date:	Wed, 06 Apr 2016 15:39:55 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	paul@...l-moore.com
Cc:	pabeni@...hat.com, linux-security-module@...r.kernel.org,
	james.l.morris@...cle.com, agruenba@...hat.com, 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

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.

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

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.