From: Paul Moore <paul@paul-moore.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, linux-security-module@vger.kernel.org,
selinux@vger.kernel.org
Subject: Re: New skb extension for use by LSMs (skb "security blob")?
Date: Wed, 21 Aug 2019 23:27:03 -0400 [thread overview]
Message-ID: <CAHC9VhRLexftb5mK8_izVQkv9w46m=aPukws2d2m+yrMvHUF_g@mail.gmail.com> (raw)
In-Reply-To: <20190821.155013.1723892743521935274.davem@davemloft.net>
On Wed, Aug 21, 2019 at 6:50 PM David Miller <davem@davemloft.net> wrote:
> From: Paul Moore <paul@paul-moore.com>
> Date: Wed, 21 Aug 2019 18:00:09 -0400
>
> > I was just made aware of the skb extension work, and it looks very
> > appealing from a LSM perspective. As some of you probably remember,
> > we (the LSM folks) have wanted a proper security blob in the skb for
> > quite some time, but netdev has been resistant to this idea thus far.
> >
> > If I were to propose a patchset to add a SKB_EXT_SECURITY skb
> > extension (a single extension ID to be shared among the different
> > LSMs), would that be something that netdev would consider merging, or
> > is there still a philosophical objection to things like this?
>
> Unlike it's main intended user (MPTCP), it sounds like LSM's would use
> this in a way such that it would be enabled on most systems all the
> time.
>
> That really defeats the whole purpose of making it dynamic. :-/
I would be okay with only adding a skb extension when we needed it,
which I'm currently thinking would only be when we had labeled
networking actually configured at runtime and not just built into the
kernel. In SELinux we do something similar today when it comes to our
per-packet access controls; if labeled networking is not configured we
bail out of the LSM hooks early to improve performance (we would just
be comparing unlabeled_t to unlabeled_t anyway). I think the other
LSMs would be okay with this usage as well.
While a number of distros due enable some form of LSM and the labeled
networking bits at build time, vary few (if any?) provide a default
configuration so I would expect no additional overhead in the common
case.
Would that be acceptable?
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2019-08-22 3:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 22:00 New skb extension for use by LSMs (skb "security blob")? Paul Moore
2019-08-21 22:50 ` David Miller
2019-08-22 3:27 ` Paul Moore [this message]
2019-08-22 3:54 ` David Miller
2019-08-22 18:50 ` Casey Schaufler
2019-08-22 7:03 ` Florian Westphal
2019-08-22 16:32 ` Paul Moore
2019-08-22 20:10 ` Casey Schaufler
2019-08-22 20:15 ` Florian Westphal
2019-08-22 20:35 ` Casey Schaufler
2019-08-22 21:18 ` David Miller
2019-08-22 21:59 ` Casey Schaufler
2019-08-22 22:28 ` David Miller
2019-08-22 22:34 ` Casey Schaufler
2019-08-22 22:36 ` David Miller
2019-08-23 18:56 ` Casey Schaufler
2019-08-22 21:17 ` David Miller
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='CAHC9VhRLexftb5mK8_izVQkv9w46m=aPukws2d2m+yrMvHUF_g@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=davem@davemloft.net \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=selinux@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).