netdev - Re: [PATCH 3/3] selinux: Add SELinux GTP support

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: <20200930133847.GD238904@nataraja>
Date:   Wed, 30 Sep 2020 15:38:47 +0200
From:   Harald Welte <laforge@...monks.org>
To:     Richard Haines <richard_c_haines@...nternet.com>
Cc:     selinux@...r.kernel.org, linux-security-module@...r.kernel.org,
        osmocom-net-gprs@...ts.osmocom.org, netdev@...r.kernel.org,
        stephen.smalley.work@...il.com, paul@...l-moore.com,
        pablo@...filter.org, jmorris@...ei.org
Subject: Re: [PATCH 3/3] selinux: Add SELinux GTP support

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@...monks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)