On 2025-09-26 11:55, Paul Eggert via tz wrote:
On 2025-09-26 10:27, Dag-Erling Smørgrav wrote:
Second, even platforms lacking AT_RESOLVE_BENEATH get equivalent security
guarantees, because we can trust the contents of /usr/share/zoneinfo (if we
can't trust that directory, we have bigger problems than those fixable by
AT_RESOLVE_BENEATH!) and tzcode's localtime checks for ".." in relative
pathnames (I'll arrange for this check to be optimized away on platforms with
AT_RESOLVE_BENEATH).
* Although FreeBSD takes some steps to treat TZ settings the same
regardless of whether they come from the TZ environment variable, it
doesn't take this idea to its logical conclusion. It seems to me
that it's better to not care where the TZ setting came from, as
that's easier to document, understand, and maintain, so the attached
patches do that.
That's just wrong. As a setugid program, I can't trust TZ because it
was provided by an unprivileged and untrusted user, so I must defend
against attempts to break out from TZDIR. I should however be able to
trust TZDEFAULT, even if it points to something outside TZDIR, because
TZDEFAULT is controlled by the administrator, not by an untrusted user.
Ah, I should have mentioned that TZDEFAULT (default "/etc/localtime") is a
special case: its is trusted regardless of whether it came from the TZ
environment variable or from tzalloc.
If you do not allow data file paths outside TZDIR, how do we test zones in the
packaged build or staging directories, or custom or patched zones in our dev
directories?
Is it not better to apply the same untrusting attitude about TZ to all external
data, regardless of what you believe about the source, which may have been
compromised?
This seems to be how exploits are elevated from messing with relatively obscure
files which are misconfigured, accidentally or maliciously!
I never understood why effectively constant data files are installed with user
write privileges, where read only might slow attackers a smidge, and may have to
be used on systems which do not really support POSIX permissions; more
especially if that is made a checked security condition!
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
