From laforge at osmocom.org  Fri Sep  4 19:08:20 2020
From: laforge at osmocom.org (Harald Welte)
Date: Fri, 4 Sep 2020 21:08:20 +0200
Subject: OsmoDevCon  / COVID-19
Message-ID: <20200904190820.GA609235@nataraja>

Dear fellow Osmocom developers,

as you all know, we've sadly had to postpone OsmoDevCon 2020 back in
April this year.  At the time, we discussed to re-visit the situation
in October 2020.

While legally it is no problem at all to host an event with ~ 20
participants in Berlin/Germany (specific regulations really only start
from 50+ participants) - I'm not entirely convinced it would be the
smartest move.

Legality and public health regulations are only one part of the equation
- common sense and profound care for the key members of our community
for sure are more relevant considerations to me.

I'm not 100% in favour and not 100% against.  Hence, I would like to get
your input.  Should we

a) try to get an event organized on-site in Berlin?  We'd have to move
   to a larger venue than IN-Berlin with proper ventilation and sufficient
   space so we can keep physical distance, but I think that's
   manageable for sysmocom as organizer.

b) simply postpone to 2021?  I'm convinced the situation will not change
   significantly (in a positive way) until late April 2021, so it's not
   really a "solution" as it will likely mean we have to think of late
   2021 or 2022.

c) plan some kind of online conference?  To be honest, I think this
   model works fine for events where a single speaker wants to give
   lectures to hundreds or thousands of participants.  But OsmoDevCon
   is much more interactive.  We could record or live-stream some talks
   or screencasts from home, sure.  But that only captures one part of
   the event.  We could also try to set a date for a collaborative
   mumble, or the like - for the "hallway track".

What are your thoughts?  Let's avoid cross-posting the discussion to all
of the mailing lists and simply have it on openbsc at lists.osmocom.org.

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


From laforge at osmocom.org  Fri Sep 18 21:15:18 2020
From: laforge at osmocom.org (Harald Welte)
Date: Fri, 18 Sep 2020 23:15:18 +0200
Subject: ns2 thoughts
Message-ID: <20200918211518.GI1611880@nataraja>

Hi List and Lynxis,

I've been reading through the ns2 code more thoroughly and had some thoughts
for improvement.  As we have no users yet, and the code is unreleased, we
can still make changes now.

== unused argument in ns2_recv_vc

int ns2_recv_vc(struct gprs_ns2_inst *nsi,
                struct gprs_ns2_vc *nsvc,
                struct msgb *msg)

The 'nsi' is not used and should be redundant, as the nsvc has a back-pointer anyway, right?


== consider using an osmo_ prefix to all symbols / types

The fact that the old code doesn't have that is a tribute to its age, and not
something we need to keep.  The current code has quite a bit of 'gprs_ns2' prefixing for
types, but not for the symbols/functions.  At least that inconsistency should be resolved,
so all have the same prefix, even if it is without osmo.


== const-ify input arguments

If arguments pointing to data are used read-only, let's express that by
the const qualifier.  The easy ones are the likes of
"gprs_ns2_is_frgre_bind(struct gprs_ns2_vc_bind *bind)",
but there are definitely many more.


== use of msgb->dst

In several other osmocom implementations we use msgb->dst to point to the
underlying element receiving or transmitting a message.  So I could imagine
ns2_recv_vc() not only without the 'nsi' argument, but also without the
'nsvc' argument, if we introduce the convention that msgb->dst would always
point to the ns-vc.

Not sure here, it has pros and cons.  Just brainstorming.


== output arguments vs. return value

There are functions like gprs_ns2_find_vc_by_sockaddr() where the result
is not returned, but rather a **pointer output argument is used.  What
is the rationale here?   I don't understand what benefit the extra 0/1
return value gives.  The only other return value is -EINVAL if the **ptr
was NULL - an error situation that wouldn't exist if we simply returned
the pointer from the function.

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


From serge1991drum at mail.ru  Fri Sep 18 09:53:43 2020
From: serge1991drum at mail.ru (=?UTF-8?B?0KHQtdGA0LPQtdC5INCV0LPQvtGA0L7Qsg==?=)
Date: Fri, 18 Sep 2020 12:53:43 +0300
Subject: =?UTF-8?B?IEdTTSwgR1BSUw==?=
Message-ID: <1600422823.106963076@f106.i.mail.ru>


Hi!
I with my friends-students got a task to investigate ciphering algorithm GEA3, using in GPRS/EDGE.
While communication MS and Osmocom base station (BS) we've got the LLC-message:
LLC MESSAGE (ciphered): 01C00F1840623297A594EE196714A2653D23D5A2AC52792F0434
with the following parameters:
Cipher Algorithm: ?GEA3
Kc_GPRS: A8FC3A996A80D000
SAPI: 1?
NU: 3?
IOV_UI: 0?
OC: 0?
After applying algorithm GEA3 we've got deciphered LLC-message:
LLC MESSAGE (deciphered): 01C00F0802012A0452F00300010017161805F4D7BF04CA 26176B
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
We get, calculated FCS (6B1726) using deciphered LLC-message and contained in LLC-message FCS (6B1726) are equal.
?
While communication MS and the real BS we've got the following LLC-message:
LLC MESSAGE (ciphered) ?41C00B9299A1EB51A1AD1FE71633786B23CBD8E6D41C9F658C89C9544AF2BAAC35
with the following parameters:
Cipher Algorithm: ?GEA3
KC_GPRS: 8f94a69c3d9bdf48
SAPI: 1
NU: ?2
IOV_UI: 0x10000000 (got from XID)
OC: from 0 to  8388608
So we tried to apply the OC parameter from 0 to  8388608 to decipher the message (other parameters were not been changed).
In every step, we calculated FCS and compared it with contained in LLC-message FCS and had no success.
Finally the question:
Can the value of IOV_UI (Osmocom BS: 0, real BS: 0x10000000) affect the deciphering, and if yes then how??
With regards, students of the telecommunication department.

Thank you for your attention!
?
Best regards, Sergei
?
----------------------------------------------------------------------
? ?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20200918/f722b1c6/attachment.htm>

From serge1991drum at mail.ru  Fri Sep 18 07:48:03 2020
From: serge1991drum at mail.ru (=?UTF-8?B?0KHQtdGA0LPQtdC5INCV0LPQvtGA0L7Qsg==?=)
Date: Fri, 18 Sep 2020 10:48:03 +0300
Subject: =?UTF-8?B?IEdTTSwgR1BSUw==?=
Message-ID: <1600415283.658229349@f385.i.mail.ru>


?
Good afternoon!
I with my friends-students got a task to investigate ciphering algorithm GEA3, using in GPRS/EDGE.
While communication MS and Osmocom base station (BS) we've got the LLC-message:
LLC MESSAGE (ciphered): 01C00F1840623297A594EE196714A2653D23D5A2AC52792F0434
with the following parameters:
Cipher Algorithm: ?GEA3
Kc_GPRS: A8FC3A996A80D000
SAPI: 1?
NU: 3?
IOV_UI: 0?
OC: 0?
After applying algorithm GEA3 we've got deciphered LLC-message:
LLC MESSAGE (deciphered): 01C00F0802012A0452F00300010017161805F4D7BF04CA 26176B
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
We get, calculated FCS (6B1726) using deciphered LLC-message and contained in LLC-message FCS (6B1726) are equal.
?
While communication MS and the real BS we've got the following LLC-message:
LLC MESSAGE (ciphered) ?41C00B9299A1EB51A1AD1FE71633786B23CBD8E6D41C9F658C89C9544AF2BAAC35
with the following parameters:
Cipher Algorithm: ?GEA3
KC_GPRS: 8f94a69c3d9bdf48
SAPI: 1
NU: ?2
IOV_UI: 0x10000000 (got from XID)
OC: from 0 to  8388608
So we tried to apply the OC parameter from 0 to  8388608 to decipher the message (other parameters were not been changed).
In every step, we calculated FCS and compared it with contained in LLC-message FCS and had no success.
Finally the question:
Can the value of IOV_UI (Osmocom BS: 0, real BS: 0x10000000) affect the deciphering, and if yes then how??
With regards, students of the telecommunication department.

Thank you for your attention!
?
Best regards, Sergei
?
?
----------------------------------------------------------------------
? ?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20200918/71bf96ad/attachment.htm>

From laforge at osmocom.org  Sun Sep 20 11:55:54 2020
From: laforge at osmocom.org (Harald Welte)
Date: Sun, 20 Sep 2020 13:55:54 +0200
Subject: GSM, GPRS
In-Reply-To: <1600422823.106963076@f106.i.mail.ru>
References: <1600422823.106963076@f106.i.mail.ru>
Message-ID: <20200920115554.GB2019632@nataraja>

Dear Sergei,

I'm not an expert in GEA and it's been a long time since I last looked at it.

However,

On Fri, Sep 18, 2020 at 12:53:43PM +0300, ?????? ?????? wrote:
> Can the value of IOV_UI (Osmocom BS: 0, real BS: 0x10000000) affect the deciphering, and if yes then how??

well, as you know the IV (initialization vector) is an input parameter into the 
encryption/decryption algorithm.  It must match, otherwise you will get completely
different results.

You could try to modify the Osmocom stack (here: OsmoSGSN) to also use the same IV
that you see in your commercial/production netwokr, and see if that gets you any
further in understanding any differences?

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


From lynxis at fe80.eu  Mon Sep 21 15:50:17 2020
From: lynxis at fe80.eu (Alexander 'lynxis' Couzens)
Date: Mon, 21 Sep 2020 17:50:17 +0200
Subject: ns2 thoughts
In-Reply-To: <20200918211518.GI1611880@nataraja>
References: <20200918211518.GI1611880@nataraja>
Message-ID: <20200921175017.02906ee8@lazus.yip>

hi harald,


thanks for your review.

> I've been reading through the ns2 code more thoroughly and had some
> thoughts for improvement.  As we have no users yet, and the code is
> unreleased, we can still make changes now.
> 
> == unused argument in ns2_recv_vc
> 
> int ns2_recv_vc(struct gprs_ns2_inst *nsi,
>                 struct gprs_ns2_vc *nsvc,
>                 struct msgb *msg)
> 
> The 'nsi' is not used and should be redundant, as the nsvc has a
> back-pointer anyway, right?

Ack.
 
> == consider using an osmo_ prefix to all symbols / types
> 
> The fact that the old code doesn't have that is a tribute to its age,
> and not something we need to keep.  The current code has quite a bit
> of 'gprs_ns2' prefixing for types, but not for the symbols/functions.
>  At least that inconsistency should be resolved, so all have the same
> prefix, even if it is without osmo.

The concept was prefix gprs_ns2 for public symbols and ns2 for
internal since some functions are used across files within libosmocore.
The osmo_ prefix sounds a lot cleaner.

> == const-ify input arguments
> 
> If arguments pointing to data are used read-only, let's express that
> by the const qualifier.  The easy ones are the likes of
> "gprs_ns2_is_frgre_bind(struct gprs_ns2_vc_bind *bind)",
> but there are definitely many more.

Ack.

> == use of msgb->dst
> 
> In several other osmocom implementations we use msgb->dst to point to
> the underlying element receiving or transmitting a message.  So I
> could imagine ns2_recv_vc() not only without the 'nsi' argument, but
> also without the 'nsvc' argument, if we introduce the convention that
> msgb->dst would always point to the ns-vc.
> 
> Not sure here, it has pros and cons.  Just brainstorming.

Not sure if the effort for the msgb->dst is worth because we're only
using it internal. I don't have an opinion on this.
Except if we want to use the pointer for the resource distribution
function [48.016 4.4a].

> == output arguments vs. return value

> There are functions like gprs_ns2_find_vc_by_sockaddr() where the
> result is not returned, but rather a **pointer output argument is
> used.  What is the rationale here? 

In general I like the difference between result and return code.
ACK on gprs_ns2_find_vc_by_sockaddr() where there isn't much in the
result code.



Best Regards,
lynxis


-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20200921/cc563e52/attachment.bin>

From laforge at gnumonks.org  Mon Sep 21 17:52:19 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 Sep 2020 19:52:19 +0200
Subject: ns2 thoughts
In-Reply-To: <20200921175017.02906ee8@lazus.yip>
References: <20200918211518.GI1611880@nataraja>
 <20200921175017.02906ee8@lazus.yip>
Message-ID: <20200921175219.GX2023771@nataraja>

On Mon, Sep 21, 2020 at 05:50:17PM +0200, Alexander 'lynxis' Couzens wrote:

> > == consider using an osmo_ prefix to all symbols / types
> > 
> > The fact that the old code doesn't have that is a tribute to its age,
> > and not something we need to keep.  The current code has quite a bit
> > of 'gprs_ns2' prefixing for types, but not for the symbols/functions.
> >  At least that inconsistency should be resolved, so all have the same
> > prefix, even if it is without osmo.
> 
> The concept was prefix gprs_ns2 for public symbols and ns2 for
> internal since some functions are used across files within libosmocore.

oh, great.  I somehow missed that.

> The osmo_ prefix sounds a lot cleaner.

I guess we can keep it as-is.  If you want, go for osmo_ns2 as public
prefix, but I'm not sure it's worth the effort at this point.

> Not sure if the effort for the msgb->dst is worth because we're only
> using it internal. I don't have an opinion on this.

yes, let's just keep it as-is.

> Except if we want to use the pointer for the resource distribution
> function [48.016 4.4a].

interesting.  I'm not deep enough into the topic to have an opinion
about it right now, sorry.

> > There are functions like gprs_ns2_find_vc_by_sockaddr() where the
> > result is not returned, but rather a **pointer output argument is
> 
> In general I like the difference between result and return code.
> ACK on gprs_ns2_find_vc_by_sockaddr() where there isn't much in the
> result code.

agreed.  return the result whenever there is nothing to return.

Thanks.

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


From casey at schaufler-ca.com  Thu Sep 24 20:40:44 2020
From: casey at schaufler-ca.com (Casey Schaufler)
Date: Thu, 24 Sep 2020 13:40:44 -0700
Subject: [RFC PATCH 1/3] security: Add GPRS Tunneling Protocol (GTP)
 security hooks
In-Reply-To: <20200924085102.5960-2-richard_c_haines@btinternet.com>
References: <20200924085102.5960-1-richard_c_haines@btinternet.com>
 <20200924085102.5960-2-richard_c_haines@btinternet.com>
Message-ID: <fbf4bc81-1552-abab-a369-77de52184603@schaufler-ca.com>

On 9/24/2020 1:51 AM, Richard Haines wrote:
> The GTP security hooks are explained in:
> Documentation/security/GTP.rst
>
> Signed-off-by: Richard Haines <richard_c_haines at btinternet.com>
> ---
>  Documentation/security/GTP.rst   | 39 ++++++++++++++++++++++++++++++++
>  Documentation/security/index.rst |  1 +
>  include/linux/lsm_hook_defs.h    |  3 +++
>  include/linux/lsm_hooks.h        | 16 +++++++++++++
>  include/linux/security.h         | 19 ++++++++++++++++
>  security/security.c              | 18 +++++++++++++++
>  6 files changed, 96 insertions(+)
>  create mode 100644 Documentation/security/GTP.rst
>
> diff --git a/Documentation/security/GTP.rst b/Documentation/security/GTP.rst
> new file mode 100644
> index 000000000..e307d0b59
> --- /dev/null
> +++ b/Documentation/security/GTP.rst
> @@ -0,0 +1,39 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=============================
> +GPRS Tunneling Protocol (GTP)
> +=============================
> +
> +GTP LSM Support
> +===============
> +
> +Security Hooks
> +--------------
> +For security module support, three GTP specific hooks have been implemented::
> +
> +    security_gtp_dev_add()
> +    security_gtp_dev_del()
> +    security_gtp_dev_cmd()
> +
> +
> +security_gtp_dev_add()
> +~~~~~~~~~~~~~~~~~~~~~~
> +Allows a module to allocate a security structure for a GTP device. Returns a
> +zero on success, negative values on failure.
> +If successful the GTP device ``struct gtp_dev`` will hold the allocated
> +pointer in ``void *security;``.
> +
> +
> +security_gtp_dev_del()
> +~~~~~~~~~~~~~~~~~~~~~~
> +Allows a module to free the security structure for a GTP device. Returns a
> +zero on success, negative values on failure.
> +
> +
> +security_gtp_dev_cmd()
> +~~~~~~~~~~~~~~~~~~~~~~
> +Allows a module to validate a command for the selected GTP device. Returns a
> +zero on success, negative values on failure. The commands are based on values
> +from ``include/uapi/linux/gtp.h`` as follows::
> +
> +``enum gtp_genl_cmds { GTP_CMD_NEWPDP, GTP_CMD_DELPDP, GTP_CMD_GETPDP };``
> diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst
> index 8129405eb..cdbdaa83b 100644
> --- a/Documentation/security/index.rst
> +++ b/Documentation/security/index.rst
> @@ -16,3 +16,4 @@ Security Documentation
>     siphash
>     tpm/index
>     digsig
> +   GTP
> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> index 2a8c74d99..a994417fb 100644
> --- a/include/linux/lsm_hook_defs.h
> +++ b/include/linux/lsm_hook_defs.h
> @@ -322,6 +322,9 @@ LSM_HOOK(int, 0, sctp_bind_connect, struct sock *sk, int optname,
>  	 struct sockaddr *address, int addrlen)
>  LSM_HOOK(void, LSM_RET_VOID, sctp_sk_clone, struct sctp_endpoint *ep,
>  	 struct sock *sk, struct sock *newsk)
> +LSM_HOOK(int, 0, gtp_dev_add, void **security)

This should be gtp_dev_alloc by convention.

> +LSM_HOOK(int, 0, gtp_dev_del, void *security)

This should be gtp_dev_free by convention.

> +LSM_HOOK(int, 0, gtp_dev_cmd, void *security, enum gtp_genl_cmds cmd)

Please pass a pointer to the structure that contains the security blob,
not the pointer to the blob itself in these hooks.

>  #endif /* CONFIG_SECURITY_NETWORK */
>  
>  #ifdef CONFIG_SECURITY_INFINIBAND
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 9e2e3e637..3d6888d51 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -982,6 +982,22 @@
>   *	This hook can be used by the module to update any security state
>   *	associated with the TUN device's security structure.
>   *	@security pointer to the TUN devices's security structure.
> + * @gtp_dev_add:
> + *	This hook allows a module to allocate a security structure for a GTP
> + *	device.
> + *	@security pointer to a security structure pointer.

change per earlier comments.

> + *	Returns a zero on success, negative values on failure.
> + * @gtp_dev_del:
> + *	This hook allows a module to free the security structure for a GTP
> + *	device.
> + *	@security pointer to the GTP device's security structure.

change per earlier comments.

> + *	Returns a zero on success, negative values on failure.
> + * @gtp_dev_cmd:
> + *	This hook allows a module to free the security structure for a GTP
> + *	device.
> + *	@security pointer to the GTP device's security structure.

change per earlier comments.

> + *	@cmd contains the GTP command.
> + *	Returns a zero on success, negative values on failure.
>   *
>   * Security hooks for SCTP
>   *
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 0a0a03b36..67ff43afa 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -30,6 +30,7 @@
>  #include <linux/err.h>
>  #include <linux/string.h>
>  #include <linux/mm.h>
> +#include <linux/gtp.h>
>  
>  struct linux_binprm;
>  struct cred;
> @@ -1365,6 +1366,9 @@ int security_sctp_bind_connect(struct sock *sk, int optname,
>  			       struct sockaddr *address, int addrlen);
>  void security_sctp_sk_clone(struct sctp_endpoint *ep, struct sock *sk,
>  			    struct sock *newsk);
> +int security_gtp_dev_add(void **security);
> +int security_gtp_dev_del(void *security);
> +int security_gtp_dev_cmd(void *security, enum gtp_genl_cmds cmd);
>  
>  #else	/* CONFIG_SECURITY_NETWORK */
>  static inline int security_unix_stream_connect(struct sock *sock,
> @@ -1582,6 +1586,21 @@ static inline void security_sctp_sk_clone(struct sctp_endpoint *ep,
>  					  struct sock *newsk)
>  {
>  }
> +
> +static inline int security_gtp_dev_add(void **security)
> +{
> +	return 0;
> +}
> +
> +static inline int security_gtp_dev_del(void *security)
> +{
> +	return 0;
> +}
> +
> +static inline int security_gtp_dev_cmd(void *security, enum gtp_genl_cmds cmd)
> +{
> +	return 0;
> +}
>  #endif	/* CONFIG_SECURITY_NETWORK */
>  
>  #ifdef CONFIG_SECURITY_INFINIBAND
> diff --git a/security/security.c b/security/security.c
> index 70a7ad357..63b656848 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -2304,6 +2304,24 @@ void security_sctp_sk_clone(struct sctp_endpoint *ep, struct sock *sk,
>  }
>  EXPORT_SYMBOL(security_sctp_sk_clone);
>  
> +int security_gtp_dev_add(void **security)
> +{
> +	return call_int_hook(gtp_dev_add, 0, security);
> +}
> +EXPORT_SYMBOL(security_gtp_dev_add);
> +
> +int security_gtp_dev_del(void *security)
> +{
> +	return call_int_hook(gtp_dev_del, 0, security);
> +}
> +EXPORT_SYMBOL(security_gtp_dev_del);
> +
> +int security_gtp_dev_cmd(void *security, enum gtp_genl_cmds cmd)
> +{
> +	return call_int_hook(gtp_dev_cmd, 0, security, cmd);
> +}
> +EXPORT_SYMBOL(security_gtp_dev_cmd);
> +
>  #endif	/* CONFIG_SECURITY_NETWORK */
>  
>  #ifdef CONFIG_SECURITY_INFINIBAND


From pablo at netfilter.org  Wed Sep 30 10:17:36 2020
From: pablo at netfilter.org (Pablo Neira Ayuso)
Date: Wed, 30 Sep 2020 12:17:36 +0200
Subject: [PATCH 0/3] Add LSM/SELinux support for GPRS Tunneling Protocol
 (GTP)
In-Reply-To: <20200930094934.32144-1-richard_c_haines@btinternet.com>
References: <20200930094934.32144-1-richard_c_haines@btinternet.com>
Message-ID: <20200930101736.GA18687@salvia>

On Wed, Sep 30, 2020 at 10:49:31AM +0100, Richard Haines wrote:
> These patches came about after looking at 5G open source in particular
> the updated 5G GTP driver at [1]. As this driver is still under
> development, added the LSM/SELinux hooks to the current stable GTP
> version in kernel selinux-next [2]. Similar hooks have also been
> implemented in [1] as it uses the same base code as the current 3G
> version (except that it handles different packet types).

Yes, [1] looks like it is based on the existing 3G driver in the Linux
tree.

> To test the 3G GTP driver there is an RFC patch for the selinux-testsuite
> at [3].
> 
> To enable the selinux-testsuite GTP tests, the libgtpnl [4] library and
> tools needed to be modified to:
> Return ERRNO on error to detect EACCES, Add gtp_match_tunnel function,
> Allow gtp-link to specify port numbers for multiple instances to
> run in the same namespace.
> 
> A patch for libgtpnl is supplied in the selinux-testsuite patch as well
> as setup/test instructions (libgtpnl is not packaged by Fedora)
> 
> These patches were tested on Fedora 32 with kernel [2] using the
> 'targeted' policy. Also ran the Linux Kernel GTP-U basic tests [5].

I don't remember to have seen anything similar in the existing tunnel
net_devices.

Why do you need this?

> [1] https://github.com/PrinzOwO/gtp5g


From laforge at gnumonks.org  Wed Sep 30 11:01:53 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 30 Sep 2020 13:01:53 +0200
Subject: [PATCH 3/3] selinux: Add SELinux GTP support
In-Reply-To: <20200930094934.32144-4-richard_c_haines@btinternet.com>
References: <20200930094934.32144-1-richard_c_haines@btinternet.com>
 <20200930094934.32144-4-richard_c_haines@btinternet.com>
Message-ID: <20200930110153.GT3871@nataraja>

Hi Richard,

I don't fully understand in which context you need / use those SELinux GTP hooks,
however one comment from the point of view of somebody who is working on GGSN/P-GW
software using the GTP kernel module:

On Wed, Sep 30, 2020 at 10:49:34AM +0100, Richard Haines wrote:
> +selinux_gtp_dev_cmd()
> +~~~~~~~~~~~~~~~~~~~~~
> +Validate if the caller (current SID) and the GTP device SID have the required
> +permission to perform the operation. The GTP/SELinux permission map is
> +as follow::
> +
> +    GTP_CMD_NEWPDP = gtp { add }
> +    GTP_CMD_DELPDP = gtp { del }
> +    GTP_CMD_GETPDP = gtp { get }

Wouldn't it make sense to differentiate between:

a) add/del/get on the GTP netdev
b) add/del/get on the indivudual PDP wihin the GTP netdev

'a' is typically only created once at startup of a GGSN/P-GW software, or is
done even at system stat-up time.

'b' is performed frequently during runtime as the GGSN/P-GW function runs, as
subscribers attach to / detach from the cellular network.

By differentiating between those two, one could further constrain the permissions
required at runtime.

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


From pablo at netfilter.org  Wed Sep 30 12:30:16 2020
From: pablo at netfilter.org (Pablo Neira Ayuso)
Date: Wed, 30 Sep 2020 14:30:16 +0200
Subject: [PATCH 0/3] Add LSM/SELinux support for GPRS Tunneling Protocol
 (GTP)
In-Reply-To: <0a5e4f19d7bb5c61985dece7614dc33329858f36.camel@btinternet.com>
References: <20200930094934.32144-1-richard_c_haines@btinternet.com>
 <20200930101736.GA18687@salvia>
 <0a5e4f19d7bb5c61985dece7614dc33329858f36.camel@btinternet.com>
Message-ID: <20200930123016.GA24952@salvia>

On Wed, Sep 30, 2020 at 01:20:41PM +0100, Richard Haines wrote:
> On Wed, 2020-09-30 at 12:17 +0200, Pablo Neira Ayuso wrote:
> > On Wed, Sep 30, 2020 at 10:49:31AM +0100, Richard Haines wrote:
> > > These patches came about after looking at 5G open source in
> > > particular
> > > the updated 5G GTP driver at [1]. As this driver is still under
> > > development, added the LSM/SELinux hooks to the current stable GTP
> > > version in kernel selinux-next [2]. Similar hooks have also been
> > > implemented in [1] as it uses the same base code as the current 3G
> > > version (except that it handles different packet types).
> > 
> > Yes, [1] looks like it is based on the existing 3G driver in the
> > Linux
> > tree.
> 
> After a few fixes to [1], I now have the gtp5g version driver running
> on 5.9 with security hooks and passing their couple of tests.
> 
> > 
> > > To test the 3G GTP driver there is an RFC patch for the selinux-
> > > testsuite
> > > at [3].
> > > 
> > > To enable the selinux-testsuite GTP tests, the libgtpnl [4] library
> > > and
> > > tools needed to be modified to:
> > > Return ERRNO on error to detect EACCES, Add gtp_match_tunnel
> > > function,
> > > Allow gtp-link to specify port numbers for multiple instances to
> > > run in the same namespace.
> > > 
> > > A patch for libgtpnl is supplied in the selinux-testsuite patch as
> > > well
> > > as setup/test instructions (libgtpnl is not packaged by Fedora)
> > > 
> > > These patches were tested on Fedora 32 with kernel [2] using the
> > > 'targeted' policy. Also ran the Linux Kernel GTP-U basic tests [5].
> > 
> > I don't remember to have seen anything similar in the existing tunnel
> > net_devices.
> > 
> > Why do you need this?
> 
> I don't actually have a use for this, I only did it out of idle
> curiosity. If it is useful to the community then okay. Given the
> attemped move to Open 5G I thought adding MAC support might be useful
> somewhere along the line.

No worries.

I'd suggest you send us patches to integrate missing code into the
existing driver, probably leaving the SELinux support aside - until we
learn how to use it or we understand the original motivation to make
it, I currently don't find any.

Thanks.


From laforge at gnumonks.org  Wed Sep 30 13:38:47 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 30 Sep 2020 15:38:47 +0200
Subject: [PATCH 3/3] selinux: Add SELinux GTP support
In-Reply-To: <33cf57c9599842247c45c92aa22468ec89f7ba64.camel@btinternet.com>
References: <20200930094934.32144-1-richard_c_haines@btinternet.com>
 <20200930094934.32144-4-richard_c_haines@btinternet.com>
 <20200930110153.GT3871@nataraja>
 <33cf57c9599842247c45c92aa22468ec89f7ba64.camel@btinternet.com>
Message-ID: <20200930133847.GD238904@nataraja>

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


From richard_c_haines at btinternet.com  Wed Sep 30 12:20:41 2020
From: richard_c_haines at btinternet.com (Richard Haines)
Date: Wed, 30 Sep 2020 13:20:41 +0100
Subject: [PATCH 0/3] Add LSM/SELinux support for GPRS Tunneling Protocol
 (GTP)
In-Reply-To: <20200930101736.GA18687@salvia>
References: <20200930094934.32144-1-richard_c_haines@btinternet.com>
 <20200930101736.GA18687@salvia>
Message-ID: <0a5e4f19d7bb5c61985dece7614dc33329858f36.camel@btinternet.com>

On Wed, 2020-09-30 at 12:17 +0200, Pablo Neira Ayuso wrote:
> On Wed, Sep 30, 2020 at 10:49:31AM +0100, Richard Haines wrote:
> > These patches came about after looking at 5G open source in
> > particular
> > the updated 5G GTP driver at [1]. As this driver is still under
> > development, added the LSM/SELinux hooks to the current stable GTP
> > version in kernel selinux-next [2]. Similar hooks have also been
> > implemented in [1] as it uses the same base code as the current 3G
> > version (except that it handles different packet types).
> 
> Yes, [1] looks like it is based on the existing 3G driver in the
> Linux
> tree.

After a few fixes to [1], I now have the gtp5g version driver running
on 5.9 with security hooks and passing their couple of tests.

> 
> > To test the 3G GTP driver there is an RFC patch for the selinux-
> > testsuite
> > at [3].
> > 
> > To enable the selinux-testsuite GTP tests, the libgtpnl [4] library
> > and
> > tools needed to be modified to:
> > Return ERRNO on error to detect EACCES, Add gtp_match_tunnel
> > function,
> > Allow gtp-link to specify port numbers for multiple instances to
> > run in the same namespace.
> > 
> > A patch for libgtpnl is supplied in the selinux-testsuite patch as
> > well
> > as setup/test instructions (libgtpnl is not packaged by Fedora)
> > 
> > These patches were tested on Fedora 32 with kernel [2] using the
> > 'targeted' policy. Also ran the Linux Kernel GTP-U basic tests [5].
> 
> I don't remember to have seen anything similar in the existing tunnel
> net_devices.
> 
> Why do you need this?

I don't actually have a use for this, I only did it out of idle
curiosity. If it is useful to the community then okay. Given the
attemped move to Open 5G I thought adding MAC support might be useful
somewhere along the line.

> 
> > [1] https://github.com/PrinzOwO/gtp5g



From richard_c_haines at btinternet.com  Wed Sep 30 12:25:27 2020
From: richard_c_haines at btinternet.com (Richard Haines)
Date: Wed, 30 Sep 2020 13:25:27 +0100
Subject: [PATCH 3/3] selinux: Add SELinux GTP support
In-Reply-To: <20200930110153.GT3871@nataraja>
References: <20200930094934.32144-1-richard_c_haines@btinternet.com>
 <20200930094934.32144-4-richard_c_haines@btinternet.com>
 <20200930110153.GT3871@nataraja>
Message-ID: <33cf57c9599842247c45c92aa22468ec89f7ba64.camel@btinternet.com>

On Wed, 2020-09-30 at 13:01 +0200, Harald Welte wrote:
> Hi Richard,
> 
> I don't fully understand in which context you need / use those
> SELinux GTP hooks,

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.

> however one comment from the point of view of somebody who is working
> on GGSN/P-GW
> software using the GTP kernel module:
> 
> On Wed, Sep 30, 2020 at 10:49:34AM +0100, Richard Haines wrote:
> > +selinux_gtp_dev_cmd()
> > +~~~~~~~~~~~~~~~~~~~~~
> > +Validate if the caller (current SID) and the GTP device SID have
> > the required
> > +permission to perform the operation. The GTP/SELinux permission
> > map is
> > +as follow::
> > +
> > +    GTP_CMD_NEWPDP = gtp { add }
> > +    GTP_CMD_DELPDP = gtp { del }
> > +    GTP_CMD_GETPDP = gtp { get }
> 
> Wouldn't it make sense to differentiate between:
> 
> a) add/del/get on the GTP netdev
> b) add/del/get on the indivudual PDP wihin the GTP netdev
> 
> 'a' is typically only created once at startup of a GGSN/P-GW
> software, or is
> done even at system stat-up time.
> 
> 'b' is performed frequently during runtime as the GGSN/P-GW function
> runs, as
> subscribers attach to / detach from the cellular network.
> 
> By differentiating between those two, one could further constrain the
> permissions
> required at runtime.

Yes, at first I did separate them (add_dev, del_dev, add_pkt, del_pkt,
get_pkt), so if this patchset goes anywhere then I can change it no
problem. I guess the '*_pkt' permissions would cover PDP for 3G and PDR
& FAR for 5G ?.
I didn't implement 'get_dev' but thought it could be useful for
retrieving the security context of a device, but that requires passing
it back via netlink so thought I would leave it until later.

> 



From casey at schaufler-ca.com  Wed Sep 30 15:56:22 2020
From: casey at schaufler-ca.com (Casey Schaufler)
Date: Wed, 30 Sep 2020 08:56:22 -0700
Subject: [PATCH 0/3] Add LSM/SELinux support for GPRS Tunneling Protocol
 (GTP)
In-Reply-To: <0a5e4f19d7bb5c61985dece7614dc33329858f36.camel@btinternet.com>
References: <20200930094934.32144-1-richard_c_haines@btinternet.com>
 <20200930101736.GA18687@salvia>
 <0a5e4f19d7bb5c61985dece7614dc33329858f36.camel@btinternet.com>
Message-ID: <c075cd58-983f-0386-4281-6ff1edb6920c@schaufler-ca.com>

On 9/30/2020 5:20 AM, Richard Haines wrote:
> On Wed, 2020-09-30 at 12:17 +0200, Pablo Neira Ayuso wrote:
> ....
>> Why do you need this?
> I don't actually have a use for this, I only did it out of idle
> curiosity. If it is useful to the community then okay. Given the
> attemped move to Open 5G I thought adding MAC support might be useful
> somewhere along the line.

I am not a fan of adding code that "might be useful someday".
There's no way to determine if it's been done correctly and
may interfere with a "real" implementation later.