Guidance on solving the username namespacing problem

[Philipp Kern]

Hey,

thanks, Sam, Simon and Russ! That was all very helpful! Much appreciated!

[Adding the systemd maintainers to the Cc for Simon's question below.]

On 1/4/2020 5:08 PM, Simon McVittie wrote:
> On Sat, 04 Jan 2020 at 13:52:51 +0100, Philipp Kern wrote:
>> now that we are talking again about standardizing user creation using
>> sysusers, I wonder if you could give me any guidance on how to attack
>> the Debian system user namespacing problem.
> 
> It's a good reminder, but I think the naming convention for system users
> is mostly orthogonal to whether they're created by adduser, useradd,
> systemd-sysusers or something else. (But see below for DynamicUser.)

Correct. I think it mostly serves as a point of transition - when you
have to touch it anyhow, you might as well be able to rename the user.
(Although in many cases it is probably rather tricky.)

>> OpenBSD rather successfully standardized on the underscore prefix to
>> eliminate this conflict altogether. I would like that we recommend the
>> same thing.
> 
> I agree that's a good convention for new system users (better than
> debian- or Debian-, and a lot better than having no particular prefix),
> particularly now that apt creates _apt on basically every Debian-derived
> system.
> 
>> The main question that has been raised was how to manage the migration.
>> I think the priority should be on stopping the bleeding and new users
>> should follow a consistent scheme
> 
> I agree, and I don't think the absence of a migration path for existing
> system users like messagebus and systemd-coredump should prevent us
> from encouraging the OpenBSD underscore thing for new system users
> like _apt and _flatpak.
> 
> I maintain several game servers that use undesirable usernames like
> Debian-openarena, which might make good test subjects for automatic
> migration to names like _openarena in relatively unimportant packages
> (we shouldn't be using more important packages like dbus as our test
> subjects). After successfully prototyping it in a couple of packages,
> the right place for it would probably be debhelper or init-system-helpers.
> 
> The thing to do during migration would probably be to add a second user
> with the same uid and other details, but a different username (like
> useradd --non-unique); then optionally remove the original user record,
> leaving only the new name.

I fear that we might need a local policy hook for migrations. If we end
up renaming users that are actively referenced elsewhere, there might be
cleanup tasks that need to be performed in lockstep.

At the same time I'd strongly suggest that we do not go the way of
distinguishing between the old user already being present on a machine
and a new package install. That's a divergence that becomes actively
harmful when you try to manage a set of machines.

> On Sat, 04 Jan 2020 at 13:55:40 +0100, Philipp Kern wrote:
>> A more bold move would be to tell daemon packagers to use DynamicUser
>> where feasible and only allocate more permanent users if there's a need
>> for it.
> 
> I think this is *almost* orthogonal to how those users are named.
> 
> The only way in which DynamicUser affects the naming policy is that if
> foo-bar.service uses DynamicUser=yes and does not specify a User, the
> default is foo-bar. /lib/systemd/system/fwupd-refresh.service is currently
> the only example on my laptop.
> 
> For units with a long, namespaced name like fwupd-refresh.service,
> flatpak-system-helper.service and quake2-server.serice, this is probably
> good enough in practice, even though in principle these names might collide.
> 
> Possible routes:
> 
> - leave these units with behaviour that does not follow the recommendation,
>   reasoning that if they have fairly long names it won't actually be a
>   practical problem
> 
> - recommend that units with DynamicUser=yes should specify a User and Group
>   that fit the naming convention, for example DynamicUser=yes,
>   User=_fwupd-refresh
> 
> - ask the systemd Debian maintainers to patch systemd so that it defaults
>   to the equivalent of User=_fwupd-refresh instead (note that this
>   behaviour change is in principle an API break which could conceivably
>   make services that work in other distributions fail to work in Debian,
>   although probably it would work fine in practice)
> 
> - ask systemd upstream to make that change (they could probably be persuaded
>   that the OpenBSD underscore thing is a good convention; same notes about
>   this being a behaviour change)
> 
> - avoid DynamicUser=yes

As I see it it isn't even guaranteed that services will have a dash,
which is quite unfortunate. That would already make them way less likely
to collide. Presumably we would not want to draw a distinction between
"contains a dash and thus does not need an underscore" and "needs an
underscore prefix to disambiguate", even though that would feel like an
easier sell as it would be a behavior change for likely significantly
less services. :/

Patching for Debian-specific behavior seems to be against the spirit of
cross-distro reusability. So that question should be posed to systemd
upstream and then we should decide based on the response?

> It's also worth noting that the 61184-65519 uid range used for DynamicUser
> by default collides with the rarely-used 60000-64999 uid range for system
> users that are "globally allocated by the Debian project, but only created
> on demand". systemd avoids uids that are already in use when allocating
> a DynamicUser, so the only time this is a practical problem is if systemd
> has already used a uid for DynamicUser, and then the package to which that
> uid is allocated in base-passwd gets installed before the next reboot.
> 
> The uids in range 60000-64999 that are really allocated in practice are
> in the sub-range 64000-64062, except for 63434 'netplan' which appears
> to be for an orphaned package that isn't in testing; so it might be
> feasible to reconfigure the DynamicUser range to 60000-63999 or similar
> in Debian's systemd?

It looks like the range must be contiguous, as it is compiled in[1].
What are the preexisting ones apart from netplan that you have in mind?
It feels like systemd's boundaries are pretty arbitrary (0xEF00 to
0xFFEF) but at the same time we might want to reserve a range for it in
policy - given that right now it is effectively squatting in that range?

The main argument presented by upstream is that it needs to be within
64bit for user namespacing to work properly. Thus I think it'd be worth
gathering what the existing use for that range really is.

> On Sat, 04 Jan 2020 at 09:00:37 -0500, Sam Hartman wrote:
>> I think you could certainly do  usernames created by packages are
>> encouraged to start with an underscore.
> ...
>> You could also do something more complex like
>> ¯
>> When maintainers choose a new hard-coded or dynamically generated username
>> for packages to use, they should start this username with an underscore.
> 
> The latter sounds better to me, at least for now.
> 
> This should probably go somewhere near §9.2.2 "UID and GID classes":
> it applies to future allocations in the 100-999 and 60000-64999 ranges,
> and maybe to future allocations in the 0-99 range (although I don't think
> we should be migrating existing low-uid hard-coded names like games and
> proxy to _games and _proxy).

That sounds fine to me too, although I wonder about placement. You are
right that it's technically about the system-assigned ranges. At the
same time it's also somewhat of a principle that might go into §9.2.1,
as that already talks about the importance of UID allocation wrt local
administration policies.

>> Note that in cases like debconf, I don't think we want an underscore
>> prepended to what the user chooses, although I think defaulting to
>> something with a leading underscore would be fine.
> 
> Yes, if a debconf prompt asks "what username should be used for the
> foo server?", it would seem appropriate to make the default _foo, but
> if the user chooses foo-server, I think rewriting it to _foo-server
> would be contrary to the principle of least astonishment.

I concur with that. Also when a sysadmin opts to use a non-underscore
name in this case they likely have some measures in place to avoid
unwanted collisions or it is not a practical problem for them.

I wonder if Sam's suggestion and then putting it into §9.2.1 and §9.2.2
(100-999) would be a valid first step:

> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -228,13 +228,16 @@ purpose for which they are allocated. This is a serious restriction, and
>  we should avoid getting in the way of local administration policies. In
>  particular, many sites allocate users and/or local system groups
>  starting at 100.
> 
>  Apart from this we should have dynamically allocated ids, which should
>  by default be arranged in some sensible order, but the behavior should
> -be configurable.
> +be configurable. When maintainers choose a new hardcoded or dynamically
> +generated username for packages to use, they should start this username
> +with an underscore. This minimizes collisions with locally created user
> +accounts.
> 
>  Packages other than ``base-passwd`` must not modify ``/etc/passwd``,
>  ``/etc/shadow``, ``/etc/group`` or ``/etc/gshadow``.
> 
>  .. _s9.2.2:
> 
> @@ -256,13 +259,14 @@ The UID and GID numbers are divided into classes as follows:
>  100-999:
>      Dynamically allocated system users and groups. Packages which need a
>      user or group, but can have this user or group allocated dynamically
>      and differently on each system, should use ``adduser --system`` to
>      create the group and/or user. ``adduser`` will check for the
>      existence of the user or group, and if necessary choose an unused id
> -    based on the ranges specified in ``adduser.conf``.
> +    based on the ranges specified in ``adduser.conf``. Usernames in this
> +    range should be prefixed with an underscore.
> 
>  1000-59999:
>      Dynamically allocated user accounts. By default ``adduser`` will
>      choose UIDs and GIDs for user accounts in this range, though
>      ``adduser.conf`` may be used to modify this behavior.

And then address this in the upgrading checklist along the lines of:

9.2 "It is now recommended to prefix usernames of newly introduced
system daemons with an underscore."

That would also seem to sidestep the systemd issue - as well as the
migration - for now.

Kind regards and thanks
Philipp Kern

[1] Queryable using pkg-config,
https://github.com/systemd/systemd/blob/master/docs/UIDS-GIDS.md#figuring-out-the-systems-uid-boundaries