Invalid error messages out of 'dbus'...how to suppress?

[Simon McVittie]

On Mon, 17 Dec 2018 at 15:04:21 -0800, L A Walsh wrote:
> dbus[6223]: Unable to set up transient service directory: XDG_RUNTIME_DIR
> "/var/run/user/5013" is owned by uid 5013, not our uid 0
> dbus[6223]: Unable to set up transient service directory: XDG_RUNTIME_DIR
> "/var/run/user/5013" is owned by uid 5013, not our uid 0
> 
> Not sure, but from the directory name it looks like this
> error message is not correct.

The warning message is correct in the sense that /var/run/user/5013 is
(presumably) owned by uid 5013, which means that if a dbus-daemon running
as uid 0 were to use /var/run/user/5013/dbus-1/services as a transient
service directory, then any uid 5013 process would be able to escalate
privileges to uid 0 by writing .service files into that directory. To
protect you from privilege escalation, dbus-daemon isn't allowing that
to happen. Because that is a loss of intended functionality, it's logging
a warning.

dbus-daemon is not really in a position to prevent privilege escalation
here: the damage has already been done, by switching privilege level
without resetting the environment (programs trust many more environment
variables than this, and in general they cannot know that they have been
run with privileges not matching their parent). This uid check is there
to catch mistakes rather than being a hard security boundary and should
not be relied on.

In general, allowing arbitrary environment variables from uid A's session
to propagate to processes with a uid B is harmful, because it tends to
cause either:

* privilege escalation from uid A to uid B beyond what you initially
  intended (uid B trusts environment variables like XDG_RUNTIME_DIR or
  PYTHONPATH or PERL5LIB or XDG_CONFIG_HOME, so if uid A can write to
  the directories named in those variables, it can influence what
  programs running as uid B do, up to and including arbitrary code
  execution)

* loss of functionality for uid B, especially when uid B is not root
  (uid B tries to read or write a directory owned by uid A and fails)

* subsequent brokenness for uid A, when uid B is root
  (root writes files or directories owned by root into a directory owned
  by uid A, and subsequently uid A fails to read, write or delete them:
  this is an especially common failure mode when running an extensible
  editor like vim or emacs as root)

Please use sudo (with env_reset enabled), "su -", pkexec, ssh, fast
user switching (virtual consoles), or some other way to swap between
privilege levels that either clears the environment completely or only
transfers selected "safe" environment variables (such as LANG and TERM)
across the privilege boundary.

    smcv