PGW without root or changing /dev/net/tun permissions

historical

Hi Harald,

Generally, NextEPC recommend to start P-GW as non-root. So, before the
starting P-GW, TUN device should be setting up properly.

Perhaps I need to adjust the TUN device permission section of the NextEPC
documentation. In fact, in general, most people don't need this doc part.
The reason I wrote was because of the docker environment. TUN didn't work
properly in docker, so if I installed udev or modified the permission it
worked.

As you suggested, I'll have to revisit this section and revise the document.

Thank you for raising this issue.

Best Regards,
    Sukchan

On Sat, Aug 17, 2019 at 10:18 PM Harald Welte <laforge at gnumonks.org> wrote:

> Hi Sukchan and friends,
>
> the installation instructions recommend changing the permissions of
> /dev/net/tun,
> which can be dangerous as it gives permissions to potentially many other
> processes.
>
> There are several better alternatives to this:
>
> 1) give CAP_NET_ADMIN permission to the pgw binary:
>    Simply execute "setcap cap_net_admin=ep /usr/local/bin/nextepc-pgwd"
>    and then you can run the process as 'nextepc' user, like the other
> processes.
>
>    The sad part about this is that nextepc-pgwd has now the power to
> reconfigure
>    anything about linux netwowrking.  The best approach would be to drop
> those
>    capabiligies after creating/configuring the tun devices using
>    prctl(PR_CAPBSET_DROP, CAP_NET_ADMIN) - this way it is ensured that
>    after start-up, no capabilities survive, and even if somebody manages
>    to get code execution in the PGW, it is not a privilege escalation.
>
> 2) create the tun devices *before* starting the P-GW, and then start the
>    PGW as non-root.  We offer this method in OsmoGGSN, see Section 8.3
>    of http://ftp.osmocom.org/docs/latest/osmoggsn-usermanual.pdf
>    This can even be done with systemd now.
>
> I suggest to first change the documentation to recomend the setcap
> approach, and then later to adopt privilege dropping or another
> approach.
>
> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190818/b6a80e70/attachment.htm>