linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Harald Welte <laforge@gnumonks.org>
To: Richard Haines <richard_c_haines@btinternet.com>
Cc: selinux@vger.kernel.org, linux-security-module@vger.kernel.org,
	osmocom-net-gprs@lists.osmocom.org, netdev@vger.kernel.org,
	stephen.smalley.work@gmail.com, paul@paul-moore.com,
	pablo@netfilter.org, jmorris@namei.org
Subject: Re: [PATCH 3/3] selinux: Add SELinux GTP support
Date: Wed, 30 Sep 2020 15:38:47 +0200	[thread overview]
Message-ID: <20200930133847.GD238904@nataraja> (raw)
In-Reply-To: <33cf57c9599842247c45c92aa22468ec89f7ba64.camel@btinternet.com>

Hi Richard,

On Wed, Sep 30, 2020 at 01:25:27PM +0100, Richard Haines wrote:

> As in the reply to Pablo, I did it for no particular reason other than
> idle curiosity, and given the attempted move to Open 5G I thought
> adding MAC support might be useful somewhere along the line.

thanks, I only saw your related mail earlier today.

Unfortunately there's a lot of talk about "open source" in the context of 5G
but as far as I can tell (and I'm involved in open source cellular full-time
for a decade now) it's mostly marketing.  And if something is relased, it's
some shared source license that doesn't pass the OSI OSD nor DFSG, ...

In any case, this is off-topic here.

I think it would not be the best idea to merge SELinux support patches for the
GTP kernel driver without thoroughly understanding the use case, and/or having
some actual userspace implementations that make use of them.  In the end, we may
be introducing code that nobody uses, and which only turns out to be insufficient
for what later actual users may want.

So like Pablo suggested, it would probably be best to focus on
submitting / merging features for things that are either well-defined (e.g.
specified in a standerd), and/or have existing userspace implementations.

> I guess the '*_pkt' permissions would cover PDP for 3G and PDR
> & FAR for 5G ?.

The permissions would probably cover those two items, yes.  As you
probably know, we currently don't have any ability in the kernel GTP
driver to map "external" IP traffic to TEID based on anything except the
destination IP address.  This is sufficient for all 2G and 3G use cases,
and should also cover many 4G use cases.  However, if you want to go for
different dedicated bearers and QoS classes, for sure you need something
more advanced in terms of classification of packets.

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

  reply	other threads:[~2020-09-30 13:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30  9:49 [PATCH 0/3] Add LSM/SELinux support for GPRS Tunneling Protocol (GTP) Richard Haines
2020-09-30  9:49 ` [PATCH 1/3] security: Add GPRS Tunneling Protocol (GTP) security hooks Richard Haines
2020-09-30  9:49 ` [PATCH 2/3] gtp: Add LSM hooks to GPRS Tunneling Protocol (GTP) Richard Haines
2020-09-30  9:49 ` [PATCH 3/3] selinux: Add SELinux GTP support Richard Haines
2020-09-30 11:01   ` Harald Welte
2020-09-30 12:25     ` Richard Haines
2020-09-30 13:38       ` Harald Welte [this message]
2020-10-12  2:09         ` Paul Moore
2020-10-12  9:38           ` Harald Welte
2020-10-13 13:55             ` Paul Moore
2020-10-13 16:38               ` Richard Haines
2020-10-13 20:42                 ` Harald Welte
2020-09-30 10:17 ` [PATCH 0/3] Add LSM/SELinux support for GPRS Tunneling Protocol (GTP) Pablo Neira Ayuso
2020-09-30 12:20   ` Richard Haines
2020-09-30 12:30     ` Pablo Neira Ayuso
2020-09-30 15:56     ` Casey Schaufler

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=20200930133847.GD238904@nataraja \
    --to=laforge@gnumonks.org \
    --cc=jmorris@namei.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=osmocom-net-gprs@lists.osmocom.org \
    --cc=pablo@netfilter.org \
    --cc=paul@paul-moore.com \
    --cc=richard_c_haines@btinternet.com \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    /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).