[PATCH 0/3] Add LSM/SELinux support for GPRS Tunneling Protocol (GTP)
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). 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]. [1] https://github.com/PrinzOwO/gtp5g [2] https://github.com/SELinuxProject/selinux-kernel [3] https://lore.kernel.org/selinux/20200924085314.6120-1-richard_c_haines@btint... [4] git://git.osmocom.org/libgtpnl.git [5] https://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing Changes from RFC patches: 1) Rework the LSM hook names and contents as suggested by Casey Schaufler. This resulted in moving the gtp_dev struct from gtp.c to include/net/gtp.h so that it is visible to the LSM modules for storing the security blob. 2) Remove pr_debug's from gtp.c security_* calls. 3) Minor GTP.rst updates. 4) Added netdev to distribution list. Richard Haines (3): security: Add GPRS Tunneling Protocol (GTP) security hooks gtp: Add LSM hooks to GPRS Tunneling Protocol (GTP) selinux: Add SELinux GTP support Documentation/security/GTP.rst | 100 ++++++++++++++++++++++++++++ Documentation/security/index.rst | 1 + drivers/net/gtp.c | 50 +++++++++----- include/linux/lsm_hook_defs.h | 3 + include/linux/lsm_hooks.h | 13 ++++ include/linux/security.h | 22 ++++++ include/net/gtp.h | 21 ++++++ security/security.c | 18 +++++ security/selinux/hooks.c | 66 ++++++++++++++++++ security/selinux/include/classmap.h | 2 + security/selinux/include/objsec.h | 4 ++ 11 files changed, 284 insertions(+), 16 deletions(-) create mode 100644 Documentation/security/GTP.rst -- 2.26.2
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?
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.
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.
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.
The SELinux GTP implementation is explained in: Documentation/security/GTP.rst Signed-off-by: Richard Haines <richard_c_haines@btinternet.com> --- Documentation/security/GTP.rst | 61 ++++++++++++++++++++++++++ security/selinux/hooks.c | 66 +++++++++++++++++++++++++++++ security/selinux/include/classmap.h | 2 + security/selinux/include/objsec.h | 4 ++ 4 files changed, 133 insertions(+) diff --git a/Documentation/security/GTP.rst b/Documentation/security/GTP.rst index c748587ec..433fcb688 100644 --- a/Documentation/security/GTP.rst +++ b/Documentation/security/GTP.rst @@ -15,6 +15,9 @@ For security module support, three GTP specific hooks have been implemented:: security_gtp_dev_free() security_gtp_dev_cmd() +The usage of these hooks are described below with the SELinux implementation +described in the `GTP SELinux Support`_ chapter. + security_gtp_dev_alloc() ~~~~~~~~~~~~~~~~~~~~~~ @@ -37,3 +40,61 @@ 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 };`` + + +GTP SELinux Support +=================== + +Policy Statements +----------------- +The following class and permissions to support GTP are available within the +kernel:: + + class gtp { add del get } + +The permissions are described in the sections that follow. + + +Security Hooks +-------------- + +The `GTP LSM Support`_ chapter above describes the following GTP security +hooks with the SELinux specifics expanded below:: + + security_gtp_dev_alloc -> selinux_gtp_dev_alloc_security(gtp) + security_gtp_dev_free -> selinux_gtp_dev_free_security(gtp) + security_gtp_dev_cmd -> selinux_gtp_dev_cmd(gtp, cmd) + + +selinux_gtp_dev_alloc_security() +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Allocates a security structure for a GTP device provided the caller has the +``gtp { add }`` permission. Can return errors ``-ENOMEM`` or ``-EACCES``. +Returns zero if the security structure has been allocated. + + +selinux_gtp_dev_free_security() +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Frees a security structure for a GTP device provided the caller has the +``gtp { del }`` permission. Can return error ``-EACCES``. Returns zero if the +security structure has been freed. + + +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 } + +Returns ``-EACCES`` if denied or zero if allowed. + +NOTES:: + 1) If the GTP device has the ``{ add }`` permission it can add device and + also add PDP's (packet data protocol). + + 2) If the GTP device has the ``{ del }`` permission it can delete a device + and also delete PDP's. diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index d6b182c11..5229a4f20 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -91,6 +91,7 @@ #include <uapi/linux/mount.h> #include <linux/fsnotify.h> #include <linux/fanotify.h> +#include <net/gtp.h> #include "avc.h" #include "objsec.h" @@ -5520,6 +5521,68 @@ static int selinux_tun_dev_open(void *security) return 0; } +static int selinux_gtp_dev_alloc_security(struct gtp_dev *gtp) +{ + struct gtp_security_struct *gtpsec; + u32 sid = current_sid(); + int err; + + err = avc_has_perm(&selinux_state, sid, sid, + SECCLASS_GTP, GTP__ADD, NULL); + if (err < 0) + return err; + + gtpsec = kzalloc(sizeof(*gtpsec), GFP_KERNEL); + if (!gtpsec) + return -ENOMEM; + + gtpsec->sid = sid; + gtp->security = gtpsec; + + return 0; +} + +static int selinux_gtp_dev_free_security(struct gtp_dev *gtp) +{ + struct gtp_security_struct *gtpsec = gtp->security; + u32 sid = current_sid(); + int err; + + err = avc_has_perm(&selinux_state, sid, gtpsec->sid, + SECCLASS_GTP, GTP__DEL, NULL); + if (err < 0) + return err; + + gtp->security = NULL; + kfree(gtpsec); + + return 0; +} + +static int selinux_gtp_dev_cmd(struct gtp_dev *gtp, enum gtp_genl_cmds cmd) +{ + struct gtp_security_struct *gtpsec = gtp->security; + u32 perm, sid = current_sid(); + + switch (cmd) { + case GTP_CMD_NEWPDP: + perm = GTP__ADD; + break; + case GTP_CMD_DELPDP: + perm = GTP__DEL; + break; + case GTP_CMD_GETPDP: + perm = GTP__GET; + break; + default: + WARN_ON(1); + return -EPERM; + } + + return avc_has_perm(&selinux_state, sid, gtpsec->sid, + SECCLASS_GTP, perm, NULL); +} + #ifdef CONFIG_NETFILTER static unsigned int selinux_ip_forward(struct sk_buff *skb, @@ -7130,6 +7193,8 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(tun_dev_attach_queue, selinux_tun_dev_attach_queue), LSM_HOOK_INIT(tun_dev_attach, selinux_tun_dev_attach), LSM_HOOK_INIT(tun_dev_open, selinux_tun_dev_open), + LSM_HOOK_INIT(gtp_dev_free_security, selinux_gtp_dev_free_security), + LSM_HOOK_INIT(gtp_dev_cmd, selinux_gtp_dev_cmd), #ifdef CONFIG_SECURITY_INFINIBAND LSM_HOOK_INIT(ib_pkey_access, selinux_ib_pkey_access), LSM_HOOK_INIT(ib_endport_manage_subnet, @@ -7204,6 +7269,7 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(inode_getsecctx, selinux_inode_getsecctx), LSM_HOOK_INIT(sk_alloc_security, selinux_sk_alloc_security), LSM_HOOK_INIT(tun_dev_alloc_security, selinux_tun_dev_alloc_security), + LSM_HOOK_INIT(gtp_dev_alloc_security, selinux_gtp_dev_alloc_security), #ifdef CONFIG_SECURITY_INFINIBAND LSM_HOOK_INIT(ib_alloc_security, selinux_ib_alloc_security), #endif diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h index 40cebde62..3865a4549 100644 --- a/security/selinux/include/classmap.h +++ b/security/selinux/include/classmap.h @@ -249,6 +249,8 @@ struct security_class_mapping secclass_map[] = { {"open", "cpu", "kernel", "tracepoint", "read", "write"} }, { "lockdown", { "integrity", "confidentiality", NULL } }, + { "gtp", + { "add", "del", "get", NULL } }, { NULL } }; diff --git a/security/selinux/include/objsec.h b/security/selinux/include/objsec.h index 330b7b6d4..311ffb6ea 100644 --- a/security/selinux/include/objsec.h +++ b/security/selinux/include/objsec.h @@ -148,6 +148,10 @@ struct perf_event_security_struct { u32 sid; /* SID of perf_event obj creator */ }; +struct gtp_security_struct { + u32 sid; /* SID of gtp obj creator */ +}; + extern struct lsm_blob_sizes selinux_blob_sizes; static inline struct task_security_struct *selinux_cred(const struct cred *cred) { -- 2.26.2
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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.
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)
On Wed, Sep 30, 2020 at 9:39 AM Harald Welte <laforge@gnumonks.org> wrote:
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.
...
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.
Having a solid use case or two is also helpful for those of us who don't have a GTP/GPRS background. I did spend some time reading a few things on GTP, but I don't feel like I've made much of a dent on understanding how it is actually used. Harald, Pablo - I know you both suggested taking a slow iterative approach to merging functionality, perhaps you could also help those of us on the SELinux side better understand some of the common GTP use cases? -- paul moore www.paul-moore.com
Hi Paul, On Sun, Oct 11, 2020 at 10:09:11PM -0400, Paul Moore wrote:
Harald, Pablo - I know you both suggested taking a slow iterative approach to merging functionality, perhaps you could also help those of us on the SELinux side better understand some of the common GTP use cases?
There really only is one use case for this code: The GGSN or P-GW function in the 3GPP network architecture. There are open source implementations like OsmoGGSN and (at least older/previos versions) of ergw, but also non-FOSS-but-shared-source (like OpenAirInterface) and proprietary software that use the existing kernel GTP for that. In a GGSN (2G/3G) or P-GW (4G), you have a control plane instance talking a control plane protocol GTP-C (GTPv1-C or GTPv2-C) with other elements in the network, such as the SGSN (2G/3G) or S-GW (4G) This control plane instance will then talk to the user plane instance (which is, in the case of the kernel GTP module, netlink) to crate PDP contexts (2G/3G) or "barers" (4G). Those PDP contexts / bearers are constantly being created, modified and torn down. Creation happens at the time your modern phone attaches to the network (once you have "mobile data" enabled). Modification happens when you start roaming around the country / coverage area as you change between larger regions. Deletion happens once you disable "mobile data' or go into airplane mode. The kernel GTP "tun" device typically represents an "APN", i.e. one specific IP network your phones/modems want to attach to. There could be multiple in parallel (e.g. public internet, private operator network for VoLTE, company-private networks). So you have one tun device per APN which is mostly static configuration, stable for months, years, ... and then you have the hightly volatile PDP contexts / bearers within each of those APN. That's why I was hinting from a security policy point of view, it makes sense to separate those two, as one only happens at system boot / application start time, and the other happens at any point during runtime of your GGSN/PGW. If you want to see how that looks on the wire, check the OsmoGGSN automatic test suite, where every test case generates a pcap file: overview at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test/ actual artefacts including per-test pcap files: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test/lastSucce... specifically, if you open https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test/lastSucce... in wirehark and filter on 'gtp', you will see the GTP-C traffic on udp port 2123, and the GTP-U traffic on UDP port 2152. This second part is where you would use the kernel-GTP-U implementation to avoid the kernel-userspace-kernel roundtrip for every user IP packet. There are many other use cases for GTP in general in other network elements such as a S-GW (which basically acts as a proxy for GTP-U), but those are not implemented in the existing Linux kernel GTP module. I think OsmoGGSN is about the most simple to understand user out there, due to its very limited code size. Check https://git.osmocom.org/osmo-ggsn/tree/lib/gtp-kernel.c for the libgtpnl interface and https://git.osmocom.org/osmo-ggsn/tree/ggsn/ggsn.c for the hearth of the logic, including the calls to the gtp_kernel_tunnel_*() API. Hope this helps, 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)
On Mon, Oct 12, 2020 at 5:40 AM Harald Welte <laforge@gnumonks.org> wrote:
Hi Paul,
On Sun, Oct 11, 2020 at 10:09:11PM -0400, Paul Moore wrote:
Harald, Pablo - I know you both suggested taking a slow iterative approach to merging functionality, perhaps you could also help those of us on the SELinux side better understand some of the common GTP use cases?
There really only is one use case for this code: The GGSN or P-GW function in the 3GPP network architecture ...
Hope this helps, Harald
It does, thank you. It looks like this patchset is not really a candidate for merging in its current form, but I didn't want to lose this information (both the patches and Harald's comments) so I created a GH issue to track this at the URL below. * https://github.com/SELinuxProject/selinux-kernel/issues/54 -- paul moore www.paul-moore.com
On Tue, 2020-10-13 at 09:55 -0400, Paul Moore wrote:
On Mon, Oct 12, 2020 at 5:40 AM Harald Welte <laforge@gnumonks.org> wrote:
Hi Paul,
On Sun, Oct 11, 2020 at 10:09:11PM -0400, Paul Moore wrote:
Harald, Pablo - I know you both suggested taking a slow iterative approach to merging functionality, perhaps you could also help those of us on the SELinux side better understand some of the common GTP use cases?
There really only is one use case for this code: The GGSN or P-GW function in the 3GPP network architecture ...
Hope this helps, Harald
It does, thank you.
It looks like this patchset is not really a candidate for merging in its current form, but I didn't want to lose this information (both the patches and Harald's comments) so I created a GH issue to track this at the URL below.
* https://github.com/SELinuxProject/selinux-kernel/issues/54
While I was not expecting these patches to be excepted for the current version, the main aim was to see what LSM security services could be implemented on possible 5G components, bearing in mind the DARPA Open Programmable Secure 5G (OPS-5G) initiative (probably 'jumping the gun' here a bit though). There is in development a 5G version of GTP at [1]. I have added the enhanced hooks to this (plus retrieve contexts via call-backs etc.), and have it running on 5.9, passing their tests. I'm not sure how far this development will go, but a starter ??. The other component that seems to be widely used in these systems is SCTP that I added hooks to a few years ago, also TCP/UDP etc. that are already well catered for. Also there would be a large amount of userspace code .... Anyway food for thought. [1] https://github.com/PrinzOwO/gtp5g
Hi Richard and list[s], On Tue, Oct 13, 2020 at 05:38:16PM +0100, Richard Haines wrote:
There is in development a 5G version of GTP at [1].
Please note that there is no such thing as "5G version of GTP". The GTP-U (user plane) did not change between 2G, 3G, 4G or even 5G: IT is still the same protocol version (GTPv1-U), which you can see from looking at 3GPP TS 29.281 even in its latest release (Rel 15), which is what the authors of the "gtp5g" github repository reference. What has changed over time is how the protocol is used, and what kind of QoS/classification features are added in order to use different GTP tunnels for different traffic (to the same subscriber / IP address) in order to subject it to different QoS within the 3GPP network. This functionality, by the way, can also be used in 4G networks, and even in 3G/2G networks that follow some of the later releases. The "gtp5g" module hence should in my point not be a separate module, but it should be broken down in incremental feature enhancements to the existing in-kernel GTP user plane module. The netlink interface should also obviously be extended in a backwards-compatible way. My most active kernel years are long gone, but I still think we never have two implementations of the same protocol (GTPv1U in this case) in the Kernel. One could of course also consider to switch to a completely new implementation / rewrite, but only if it is backwards compatible in terms of use cases as well as the netlink interface (and hence existing users of the GTPv1U kernel support).
The other component that seems to be widely used in these systems is SCTP that I added hooks to a few years ago, [...]
indeed, SCTP is extremely heavily used in all cellular systems, from 2G to 4G (with a peak in 4G), but still used on some 5G interfaces. Unfortunately it is the tradition (until today) that none of the industry players that need and use those protocols (GTP, SCTP) seem to be participating in the development and maintenance effort of related implementation. So rather than Nokia, Ericsson or others improving the in-kernel SCTP, their Linux based devices tend to roll their own [userspace] SCTP implementations. Even while in 2020 everybody in "marketing land" speaks about "open source" in the context of cellular/5G, it is not happening. It is only open-washing in order to appear attractive. In reality, anyone in this industry derives a *massive* revenue from their patent royalty collection and they would do anything but release or contribute to code that comes with an explicit or implicit patent license grant. So here we are, in 2020, where every single cellular equipment maker uses Linux, but the most relevant real open source projects in the industry are run by small enthusiast or very small players... 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)
Add security hooks to allow security modules to exercise access control over GTP. The 'struct gtp_dev' has been moved to include/net/gtp.h so that it is visible to LSM security modules where their security blob is stored. Signed-off-by: Richard Haines <richard_c_haines@btinternet.com> --- drivers/net/gtp.c | 50 ++++++++++++++++++++++++++++++++--------------- include/net/gtp.h | 21 ++++++++++++++++++++ 2 files changed, 55 insertions(+), 16 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 21640a035..100ee4f9c 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -60,21 +60,6 @@ struct pdp_ctx { struct rcu_head rcu_head; }; -/* One instance of the GTP device. */ -struct gtp_dev { - struct list_head list; - - struct sock *sk0; - struct sock *sk1u; - - struct net_device *dev; - - unsigned int role; - unsigned int hash_size; - struct hlist_head *tid_hash; - struct hlist_head *addr_hash; -}; - static unsigned int gtp_net_id __read_mostly; struct gtp_net { @@ -663,6 +648,10 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev, gtp = netdev_priv(dev); + err = security_gtp_dev_alloc(gtp); + if (err < 0) + return err; + err = gtp_encap_enable(gtp, data); if (err < 0) return err; @@ -705,7 +694,13 @@ static void gtp_dellink(struct net_device *dev, struct list_head *head) { struct gtp_dev *gtp = netdev_priv(dev); struct pdp_ctx *pctx; - int i; + int i, err; + + err = security_gtp_dev_free(gtp); + if (err < 0) { + pr_err("Failed security_gtp_dev_free() err: %d\n", err); + return; + } for (i = 0; i < gtp->hash_size; i++) hlist_for_each_entry_rcu(pctx, >p->tid_hash[i], hlist_tid) @@ -1076,6 +1071,10 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) goto out_unlock; } + err = security_gtp_dev_cmd(gtp, GTP_CMD_NEWPDP); + if (err < 0) + goto out_unlock; + if (version == GTP_V0) sk = gtp->sk0; else if (version == GTP_V1) @@ -1139,6 +1138,7 @@ static struct pdp_ctx *gtp_find_pdp(struct net *net, struct nlattr *nla[]) static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) { struct pdp_ctx *pctx; + struct gtp_dev *gtp; int err = 0; if (!info->attrs[GTPA_VERSION]) @@ -1152,6 +1152,11 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) goto out_unlock; } + gtp = netdev_priv(pctx->dev); + err = security_gtp_dev_cmd(gtp, GTP_CMD_DELPDP); + if (err < 0) + goto out_unlock; + if (pctx->gtp_version == GTP_V0) netdev_dbg(pctx->dev, "GTPv0-U: deleting tunnel id = %llx (pdp %p)\n", pctx->u.v0.tid, pctx); @@ -1208,6 +1213,7 @@ static int gtp_genl_get_pdp(struct sk_buff *skb, struct genl_info *info) { struct pdp_ctx *pctx = NULL; struct sk_buff *skb2; + struct gtp_dev *gtp; int err; if (!info->attrs[GTPA_VERSION]) @@ -1221,6 +1227,11 @@ static int gtp_genl_get_pdp(struct sk_buff *skb, struct genl_info *info) goto err_unlock; } + gtp = netdev_priv(pctx->dev); + err = security_gtp_dev_cmd(gtp, GTP_CMD_GETPDP); + if (err < 0) + goto err_unlock; + skb2 = genlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC); if (skb2 == NULL) { err = -ENOMEM; @@ -1250,6 +1261,7 @@ static int gtp_genl_dump_pdp(struct sk_buff *skb, struct net *net = sock_net(skb->sk); struct pdp_ctx *pctx; struct gtp_net *gn; + int err; gn = net_generic(net, gtp_net_id); @@ -1263,6 +1275,12 @@ static int gtp_genl_dump_pdp(struct sk_buff *skb, else last_gtp = NULL; + err = security_gtp_dev_cmd(gtp, GTP_CMD_GETPDP); + if (err < 0) { + rcu_read_unlock(); + return err; + } + for (i = bucket; i < gtp->hash_size; i++) { j = 0; hlist_for_each_entry_rcu(pctx, >p->tid_hash[i], diff --git a/include/net/gtp.h b/include/net/gtp.h index 0e16ebb2a..84b68cf8d 100644 --- a/include/net/gtp.h +++ b/include/net/gtp.h @@ -32,4 +32,25 @@ struct gtp1_header { /* According to 3GPP TS 29.060. */ #define GTP1_F_EXTHDR 0x04 #define GTP1_F_MASK 0x07 +/* + * One instance of the GTP device. + * Any LSM security module can access their security blob here. + */ +struct gtp_dev { + struct list_head list; + + struct sock *sk0; + struct sock *sk1u; + + struct net_device *dev; + + unsigned int role; + unsigned int hash_size; + struct hlist_head *tid_hash; + struct hlist_head *addr_hash; +#ifdef CONFIG_SECURITY + void *security; +#endif +}; + #endif -- 2.26.2
The GTP security hooks are explained in: Documentation/security/GTP.rst Signed-off-by: Richard Haines <richard_c_haines@btinternet.com> --- Documentation/security/GTP.rst | 39 ++++++++++++++++++++++++++++++++ Documentation/security/index.rst | 1 + include/linux/lsm_hook_defs.h | 3 +++ include/linux/lsm_hooks.h | 13 +++++++++++ include/linux/security.h | 22 ++++++++++++++++++ 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..c748587ec --- /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_alloc() + security_gtp_dev_free() + security_gtp_dev_cmd() + + +security_gtp_dev_alloc() +~~~~~~~~~~~~~~~~~~~~~~ +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_free() +~~~~~~~~~~~~~~~~~~~~~~ +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..ad4bbe042 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_alloc_security, struct gtp_dev *gtp) +LSM_HOOK(int, 0, gtp_dev_free_security, struct gtp_dev *gtp) +LSM_HOOK(int, 0, gtp_dev_cmd, struct gtp_dev *gtp, enum gtp_genl_cmds cmd) #endif /* CONFIG_SECURITY_NETWORK */ #ifdef CONFIG_SECURITY_INFINIBAND diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index 9e2e3e637..cd73319b9 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h @@ -982,6 +982,19 @@ * 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_alloc_security: + * Allocate and attach a security structure to the gtp->security field. + * @gtp contains the GTP device structure to secure. + * Returns a zero on success, negative values on failure. + * @gtp_dev_free_security: + * Deallocate and free the security structure stored in gtp->security. + * @gtp contains the GTP device structure to free. + * Returns a zero on success, negative values on failure. + * @gtp_dev_cmd: + * Check permissions according to the @cmd. + * @gtp contains the GTP device to access. + * @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..e214605c2 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; @@ -58,6 +59,8 @@ struct fs_parameter; enum fs_value_type; struct watch; struct watch_notification; +struct gtp_dev; +enum gtp_genl_cmds; /* Default (no) options for the capable function */ #define CAP_OPT_NONE 0x0 @@ -1365,6 +1368,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_alloc(struct gtp_dev *gtp); +int security_gtp_dev_free(struct gtp_dev *gtp); +int security_gtp_dev_cmd(struct gtp_dev *gtp, enum gtp_genl_cmds cmd); #else /* CONFIG_SECURITY_NETWORK */ static inline int security_unix_stream_connect(struct sock *sock, @@ -1582,6 +1588,22 @@ static inline void security_sctp_sk_clone(struct sctp_endpoint *ep, struct sock *newsk) { } + +static inline int security_gtp_dev_alloc(struct gtp_dev *gtp) +{ + return 0; +} + +static inline int security_gtp_dev_free(struct gtp_dev *gtp) +{ + return 0; +} + +static inline int security_gtp_dev_cmd(struct gtp_dev *gtp, + 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..12699a789 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_alloc(struct gtp_dev *gtp) +{ + return call_int_hook(gtp_dev_alloc_security, 0, gtp); +} +EXPORT_SYMBOL(security_gtp_dev_alloc); + +int security_gtp_dev_free(struct gtp_dev *gtp) +{ + return call_int_hook(gtp_dev_free_security, 0, gtp); +} +EXPORT_SYMBOL(security_gtp_dev_free); + +int security_gtp_dev_cmd(struct gtp_dev *gtp, enum gtp_genl_cmds cmd) +{ + return call_int_hook(gtp_dev_cmd, 0, gtp, cmd); +} +EXPORT_SYMBOL(security_gtp_dev_cmd); + #endif /* CONFIG_SECURITY_NETWORK */ #ifdef CONFIG_SECURITY_INFINIBAND -- 2.26.2
participants (5)
-
Casey Schaufler -
Harald Welte -
Pablo Neira Ayuso -
Paul Moore -
Richard Haines