CVE-2012-3524: Don't access environment variables or run dbus-launch when setuid

This matches a corresponding change in GLib.  See
glib/gutils.c:g_check_setuid().

Some programs attempt to use libdbus when setuid; notably the X.org
server is shipped in such a configuration. libdbus never had an
explicit policy about its use in setuid programs.

I'm not sure whether we should advertise such support.  However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.

Better to fix a problem caused by an interaction between two
components in *both* places if possible.

How to determine whether or not we're running in a privilege-escalated
path is operating system specific.  Note that GTK+'s code to check
euid versus uid worked historically on Unix, more modern systems have
filesystem capabilities and SELinux domain transitions, neither of
which are captured by the uid comparison.

On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup.  If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use.  Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1

So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.

On some BSD variants, there is a issetugid() function.  On other Unix
variants, we fall back to what GTK+ has been doing.

Reported-by: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
hardening: Use __secure_getenv if available

This helps us in the case where we were executed via filesystem
capabilities or a SELinux domain transition, not necessarily a plain
old setuid binary.

https://bugs.freedesktop.org/show_bug.cgi?id=52202
hardening: Ensure _dbus_check_setuid() is initialized threadsafe manner

This is a highly theoretical concern, but we might as well.

https://bugs.freedesktop.org/show_bug.cgi?id=52202
hardening: Use __secure_getenv() in *addition* to _dbus_check_setuid()

This is a further security measure for the case of Linux/glibc
when we're linked into a binary that's using filesystem capabilities
or SELinux domain transitions (i.e. not plain old setuid).

In this case, _dbus_getenv () will return NULL because it will
use __secure_getenv(), which handles those via AT_SECURE.

https://bugs.freedesktop.org/show_bug.cgi?id=52202
hardening: Remove activation helper handling for DBUS_VERBOSE

It's not really useful.

See https://bugs.freedesktop.org/show_bug.cgi?id=52202#c17
activation-helper: Ensure DBUS_STARTER_ADDRESS is set correctly

The fix for CVE-2012-3524 filters out all environment variables if
libdbus is used from a setuid program, to prevent various spoofing
attacks.

Unfortunately, the activation helper is a setuid program linking
libdbus, and this creates a regression for launched programs using
DBUS_STARTER_ADDRESS, since it will no longer exist.

Fix this by hardcoding the starter address to the default system bus
address.

Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
Signed-off-by: Colin Walters <walters@verbum.org>
Revert "hardening: Use __secure_getenv if available"

It breaks gnome-keyring-daemon at least in some
configurations; see
https://bugs.freedesktop.org/show_bug.cgi?id=52202#c24

This reverts commit 1a556443757b19fee67ef4441141246dd9cfed4f.
Revert "hardening: Use __secure_getenv() in *addition* to _dbus_check_setuid()"

Follow to reverting a556443757b19fee67ef4441141246dd9cfed4f.
See https://bugs.freedesktop.org/show_bug.cgi?id=52202#c24

This reverts commit d7ffad72146c2329692e0cf32eb1ac1dbb4fb51c.