From Newsgroup: alt.os.linux.debian
On 2024-01-18, David Chmelik <
dchmelik@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
--- Synchronet 3.21d-Linux NewsLink 1.2