Project

General

Profile

Actions

Feature #4107

open

Start systemd services as non-root user

Added by osmith over 2 years ago. Updated 10 months ago.

Status:
New
Priority:
High
Assignee:
Target version:
-
Start date:
07/15/2019
Due date:
% Done:

0%

Spec Reference:

Description

laforge wrote in OS#3369:

Ideally, as far as possible, we should start them as non-root user
(which may require changes to our systemd service files, etc. in the
individual git repos - but that is fine!). Starting them as non-root
will also means that any writes to unintended directories like '/'will
be discovered as they then would make the program start fail.


Related issues

Related to Cellular Network Infrastructure - Bug #3369: no automatic testing of Debian/Ubuntu packagesResolvedosmith06/29/2018

Actions
Related to Cellular Network Infrastructure - Bug #4821: Update working dir in systemd unit files Newosmith10/20/2020

Actions
Related to OsmoGGSN (former OpenGGSN) - Bug #2250: OpenGGSN requires to run as root for no apparent reasonClosedlaforge05/10/2017

Actions
Actions #1

Updated by osmith over 2 years ago

  • Related to Bug #3369: no automatic testing of Debian/Ubuntu packages added
Actions #2

Updated by laforge almost 2 years ago

  • Priority changed from Normal to Low
Actions #3

Updated by laforge about 1 year ago

Programs like osmo-msc, osmo-sgsn, osmo-cbc, osmo-smlc, osmo-hlr have no real time requirements or special needs in terms of raw networks sockets or tun devices. All of those should be executed as normal, non-privileged user from the start. This could be done via the systemd unit files. This could be done via the systemd unit files, or explicitly inside the osmocom programs via a privilege dropping approach.

the only processes that need special privileges are (AFAICT):
  • osmo-gbproxy requires CAP_NET_RAW if IPPROTO_GTP sockets are required for FR/GRE/IP
  • osmo-trx, osmo-bts, osmo-pcu requires CAP_SYS_NICE if SCHED_RR is to be used per command line argument (and is not done by e.g. systemd before starting it)
  • osmo-ggsn requires CAP_NET_ADMIN for setting up the gtp0/tun0 devices (unless this is done externally before starting it)
  • any program requires CAP_SYS_NICE if it uses the relatively new libosmocore/src/vty/cpu_sched_vty.c code to have user-configured scheduling
For those above, we basically have three possible strategies:
  • at least drop all privileges except those we really ever need in the specific proram (CAP_NET_RAW / CAP_NET_ADMIN / CAP_SYS_NICE). We can first constrain the permitted capabilities using cap_set_flag, then use prctl(PR_SET_KEEPCAPS, 1L) to keep capabilities while changing from root to non-root, and then change the user ID / group ID. https://stackoverflow.com/a/13186076 has a nice example
  • if it is sufficient to perform those privileged operations once on start-up, we could even drop those capabilities after perfoming the operations like creating netdev, binding socket, changing scheduler policy. This would mean that no subsequent changes can be made later on.
Actions #4

Updated by laforge about 1 year ago

  • Assignee deleted (osmith)
  • Priority changed from Low to High
Actions #5

Updated by keith about 1 year ago

  • Related to Bug #4821: Update working dir in systemd unit files added
Actions #6

Updated by laforge 10 months ago

  • Assignee set to osmith
IMHO, we should start by
  • create an osmocom user during package installation (if it doesn't exist yet)
    • alternatively call it osmo-cni if osmocom is deemed too generic
  • modify the systemd.service files to run the processes as that user
  • modify /etc/osmocom and its contents to be owned by that user
  • modify /var/lib/osmocom (HLR + SMS databases) to be owned by that user

For some programs, this is a no-brainer (e.g. BSC, MSC, SGSN)

For some others (TRX, BTS but possibly also MGW: SCHED_RR; GGSN: tun devices) we should work with capabilities, as described above.

Actions #7

Updated by laforge 10 months ago

  • Related to Bug #2250: OpenGGSN requires to run as root for no apparent reason added
Actions #8

Updated by osmith 10 months ago

laforge wrote:

IMHO, we should start by
  • modify /etc/osmocom and its contents to be owned by that user

That's untypical - do we want the programs to be able to change their own configs?

Actions #9

Updated by pespin 10 months ago

osmith wrote:

laforge wrote:

IMHO, we should start by
  • modify /etc/osmocom and its contents to be owned by that user

That's untypical - do we want the programs to be able to change their own configs?

We should, otherwise the user cannot store back the running-config to the .cfg file through VTY command.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)