[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCObXXrfD4H1h4t5@remnant.pseudorandom.co.uk>
Date: Tue, 13 May 2025 20:19:57 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: screen: Multiple Security Issues in Screen
(mostly affecting release 5.0.0 and setuid-root installations)
On Tue, 13 May 2025 at 18:37:44 +0200, Dr. Thomas Orgis wrote:
>that doesn't compile. A numeric value is expected.
>
>./configure --with-pty-mode=0620 --with-pty-group=$(getent group tty|cut -f 3 -d :)
>
>is closer to what also the default for screen-5.0.0 configure is.
>
>AC_ARG_WITH(pty-mode, AS_HELP_STRING([--with-pty-mode],
> [set pty mode (default: 0622)]),
> [with_pty_mode=$withval],
> [with_pty_mode=0622])
>AC_ARG_WITH(pty-group, AS_HELP_STRING([--with-pty-group],
> [set pty group (default: 5)]),
> [with_pty_group=$withval],
> [with_pty_group=5])
>
>
>Which brings me to the question if it is really smart to hardcode the
>numeric group ID. I observe wildly changing system user/group IDs in
>distros that create the accounts on the fly when installing packages.
In general yes, group IDs vary and can't be hard-coded; but for tty,
specifically, it seems to be common for it to be hard-coded as a numeric
gid. One reason for group IDs to be hard-coded in this way is if they
need to work as expected on incomplete or minimal installations that
lack the usual infrastructure around passwd(5) etc.; another is if they
need to remain usable during recovery of broken installations where that
infrastructure isn't working, and a third is during early boot where
that infrastructure might not work *yet*.
In at least Debian (presumably other distros), there are some small
ranges reserved for user and group IDs that are fixed in all
installations of the distro and can safely be hard-coded into binaries
(in Debian, 0-99 is the one that contains tty), and a considerably
larger range available for dynamic allocation (in Debian, 100-999 is the
main range for this purpose).
https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes
is the canonical reference for this in Debian and its derivatives.
>Maybe tty is always present on install images already … and happens to
>always be numeric ID 5, everywhere?
This is its value in Debian and all Debian derivatives, and in practice
seems to be common to "most" distributions - for example it's also used
in Fedora, despite neither Debian nor Fedora being a derivative of the
other (reference:
https://src.fedoraproject.org/rpms/setup/blob/rawhide/f/uidgid)
systemd also hard-codes 5 as its default for its "tty-gid" build-time
option, and installs a sysusers.d(5) snippet that will create the tty
group with the configured gid if it doesn't already exist (which seems
to be the route by which for example Arch ends up with the tty group
having gid 5).
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
