standardize uid:gid?

[David Chmelik]

Couldn't Debian standardize uid:gid numbers for daemons? The oldest--and
only strictly UNIX-like--GNU/Linux (Slackware) does this so if you install
multiple instances and want them the same, you can backup /etc/passwd & /
etc/group from one and use them on another (as long as there aren't
different users which is sometimes the case). This standardization was
probably from UNIX/*BSD.
What happens every time I can't use *BSD or Slackware on a server and
resort to Devuan (or Debian-based for some users' PCs) is that all the
uid:gid seem random so there's no way to administer them all with the same
files in cases that it'd work. Having random uid:gid is a last-rate
style.

[John Goerzen]

On 2024-01-18, David Chmelik <dchm...@gmail.com> wrote:
> Couldn't Debian standardize uid:gid numbers for daemons? The oldest--and
> only strictly UNIX-like--GNU/Linux (Slackware) does this so if you install
> multiple instances and want them the same, you can backup /etc/passwd & /
> etc/group from one and use them on another (as long as there aren't
> different users which is sometimes the case). This standardization was
> probably from UNIX/*BSD.

Some are; see
https://www.debian.org/doc/manuals/securing-debian-manual/ch12.en.html#faq-os-users

and

https://www.debian.org/doc/debian-policy/ch-opersys.html#users-and-groups

> What happens every time I can't use *BSD or Slackware on a server and
> resort to Devuan (or Debian-based for some users' PCs) is that all the
> uid:gid seem random so there's no way to administer them all with the same
> files in cases that it'd work. Having random uid:gid is a last-rate

In what way are you having difficulties? Most (all?) tools would work by
username/groupname.

Perversely, having a lot of things hardcoded limits the administrator's ability
to keep things in sync across systems. What UID do you use for a
locally-compiled service? Will your OS later conflict with it?

You can preallocate ones you care about if desired in Debian (adduser/addgroup
can be part of your setup scripts for a system).

> style.

Actually, with systemd, there's even more flexibility. Systemd can very easily
constrain a daemon's runtime environment for security. For instance, by
enabling seccomp, setting a restricted set of capabilities, or even its own
mount or network namespaces. DynamicUser is an interesting option, particularly
for daemons that don't require files to exist on disk after they are terminated.

For instance, you could use this with yggdrasil (although I don't, because it is
a little more difficult when run inside a Docker container). Even so, in
yggdrasil's default systemd service file, I ship:

ProtectHome=true
ProtectSystem=strict
NoNewPrivileges=true
RuntimeDirectory=yggdrasil
ReadWritePaths=/var/run/yggdrasil /run/yggdrasil
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

In other words, there is a tightly-defined set of directories to which it can
write, /home is entirely hidden from it, even if it somehow gains root it can't
do anything other than CAP_NET_ADMIN and CAP_NET_BIND_SERVICE, etc. You can
easily add DynamicUser into this mix and not even require an entry in
/etc/passwd or group for it at all.

Not a lot of software (yet) fits the profile for DynamicUser, but I would expect
that to change as awareness of systemd's security features increases and Docker
support for nested namespaces gets easier.

- John