All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
	Florian Westphal <fw@strlen.de>,
	linux-security-module@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	James Morris <james.l.morris@oracle.com>,
	Andreas Gruenbacher <agruenba@redhat.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	netdev@vger.kernel.org, selinux@tycho.nsa.gov
Subject: Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed
Date: Fri, 15 Apr 2016 11:38:53 +0200	[thread overview]
Message-ID: <1460713133.7410.2.camel@redhat.com> (raw)
In-Reply-To: <CAHC9VhSgWAoWgywOZOvT76jCcHuEywjFu5CKJo9D0k+66RbFCA@mail.gmail.com>

On Thu, 2016-04-14 at 18:53 -0400, Paul Moore wrote:
> On Tue, Apr 12, 2016 at 4:52 AM, Paolo Abeni <pabeni@redhat.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?

Yes, AFAIC it makes sense. I'll try to follow this route for an eventual
v2.

> 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.

Casey, are you ok with the above?

Thank you,

Paolo

  reply	other threads:[~2016-04-15  9:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-06  9:51 [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed Paolo Abeni
2016-04-06  9:51 ` [RFC PATCH 1/2] security: add hook for netlabel status change notification Paolo Abeni
2016-04-06  9:51 ` [RFC PATCH 2/2] selinux: implement support for dynamic net hook [de-]registration Paolo Abeni
2016-04-06 22:32   ` Casey Schaufler
2016-04-06 12:33 ` [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed Paul Moore
2016-04-06 14:03   ` Paolo Abeni
2016-04-06 14:07     ` Paul Moore
2016-04-06 18:23       ` David Miller
2016-04-06 18:36         ` Paul Moore
2016-04-06 19:39           ` David Miller
2016-04-06 20:07             ` Paul Moore
2016-04-06 22:14   ` Florian Westphal
2016-04-06 23:15     ` Paul Moore
2016-04-06 23:45       ` Florian Westphal
2016-04-07 18:55         ` Paul Moore
2016-04-12  8:52           ` Paolo Abeni
2016-04-12 13:57             ` Casey Schaufler
2016-04-13 11:57               ` Paolo Abeni
2016-04-13 15:06                 ` Casey Schaufler
2016-04-14 22:53             ` Paul Moore
2016-04-15  9:38               ` Paolo Abeni [this message]
2016-04-15 15:54                 ` Casey Schaufler
2016-04-06 21:37 ` Casey Schaufler
2016-04-06 21:43   ` Paul Moore
2016-04-06 21:43 ` Casey Schaufler
2016-04-07  7:59   ` Paolo Abeni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1460713133.7410.2.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=agruenba@redhat.com \
    --cc=casey@schaufler-ca.com \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=james.l.morris@oracle.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.