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: <CAHC9VhSgWAoWgywOZOvT76jCcHuEywjFu5CKJo9D0k+66RbFCA@mail.gmail.com>
Date:	Thu, 14 Apr 2016 18:53:54 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Paolo Abeni <pabeni@...hat.com>,
	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Florian Westphal <fw@...len.de>,
	linux-security-module@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	James Morris <james.l.morris@...cle.com>,
	Andreas Gruenbacher <agruenba@...hat.com>,
	Stephen Smalley <sds@...ho.nsa.gov>, netdev@...r.kernel.org,
	selinux@...ho.nsa.gov
Subject: Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed

On Tue, Apr 12, 2016 at 4:52 AM, Paolo Abeni <pabeni@...hat.com> wrote:
> Will be ok if we post a v2 version of this series, removing the hooks
> de-registration bits, but preserving the selinux nf-hooks and
> socket_sock_rcv_skb() on-demand/delayed registration ? Will that fit
> with the post-init read only memory usage that you are planning ?

The work Florian and and I were talking about would be limited just to
the netfilter hooks, the LSM hooks, e.g. socket_sock_rcv_skb() and
friends, would remain as they are today.  What what we discussing was
defaulting to not registering the netfilter hooks until it became
necessary due to a labeled networking configuration or the
always_check_network policy capability; the registration of the
netfilter hooks would be permanent, you could not unregister the hooks
at that point, you would need to reboot.  Does that make sense?

As far as Casey's concerns, I don't think the work we are talking
about for the v2 patchset would have any effect on the socket/sock
security blobs as you really can't manage those adequately from the
netfilter hooks; you most likely will reference them and perhaps even
update the data within, but not allocate or free the blobs.  Besides,
even in some weird case you were alloc/free'ing security blobs in the
netfilter hooks, we can deal with that on a per-LSM basis if/when the
full fledged stacking patches are merged; everything we are talking
about is a hidden implementation detail so changing it in the future
shouldn't be a problem.

-- 
paul moore
www.paul-moore.com