An restriction on setuid/setgid binaries linked against libc will arrive
soon, and this is another prep step.
The libc startup code is aware of the executable file's setuid/setgid
bits (via new AUX_openbsd_execmode), and will compare these bits
against a global (weak) variable "mode_t _permit_setugid" in the main
program dso -- which must indicate similar abilities.
If the binary does not contain that variable, it picks up the weak libc
version which is 0. If the corresponding bits are not set right, it means
this binary was not intended to be setuid/setgid.
The file has become setuid/setgid accidentally, unintentionally, or
due to attacker control, and libc will log the event and abort (the
abort is disabled until we complete more steps of this transition).
This change in bsd.prog.mk automatically (based upon BINMODE) creates
an additional .c file with the correct variable definition to compile
and link into the program, so that we don't need any additional changes
in userland base.
The list of ignored environment variables and the conditions under
which they are ignored or removed from downstream environment has
become too complicated to list at every specific variable, so replace
all of them a single note at the end which also mentions the new
restriction for binary readability.
If AUX_openbsd_execmode lacks S_IRUSR, disable a plethora of LD_*
environment variables which emit information about the binary at
startup. Some of these are minor info leaks, like the exec address of
the binary and shared library locations. For binaries which are unreadable,
we should respect the wishes of whoever set the mode restrictively.
I made a few more relinked binaries non-readable, and dgl pointed out
that ld.so was leaking too much information so this is the fix.
AUX_openbsd_execmode's au_v provides a mode_t containing S_ISUID and
S_ISGUID from the executable file's mode_t, and S_IRUSR which says
whether the executable file was openable for read-access (with the
process' uid/gids and the file's mode_t permissions).
ok kettenis and others
ADB macppc systems as well as macppc laptops store the time in their
nonvolatile clock, as a 32-bit unsigned integer value for the number of seconds
since 1904, and that number happens to wrap around in february 2040.
When reading a possibly truncated value which is below 1970, assume this is
actually a truncated value from after 2040.
ok deraadt@
In rc_exec() make sure we join all the arguments with spaces into a single
string. None of our rc.d scripts are affected (they all quote rc_exec commands)
but better safe than sorry for future scripts.
No behavior change.
