On Thursday, November 05, 2015 11:24:08 AM Robert Jacobson wrote:
How does one audit when the user performs an action that normally
requires elevated privileges?
TL;DR: you can't. See below for the whole story.
Right now I'm allowing my users to shutdown/reboot systems, using
Gnome menu item(s) and/or power button on the login screen.
The login screen would not have a auid associated with it, so this would
normally be forbidden.
I would like to audit this specific event but I don't know how to
it. Just auditing the execution of /sbin/shutdown doesn't give me
sufficient information in order to determine that the reboot was a
result of a user clicking the gnome GUI item. I don't even see a
message that indicates the uid of the user in connection with the
This is a known issue. Its history goes way back. The crux of the issue is
that the desktop does not go through common criteria and thus has no plumbing
for auditing. What plumbing you might ask? The issue is dbus.
The desktop uses a different execution model than the console which is fork
execve. The desktop uses dbus and activation to start helpers. This means that
if you place a watch on something that gets set by a privileged helper on the
backend of dbus, you get an auid of -1 because dbus is a daemon.
So, why doesn't dbus just set the auid on the backend? Its related to the two
generals problem: https://en.wikipedia.org/wiki/Two_Generals'_Problem
With that in mind, we het the following:
1) We need a way for closely related processes to transfer some credentials,
2) We cannot weaken the non-repudiation qualities already established.
3) It cannot allow "token kidnapping" style attacks. (Windows impersonation
had design/implementation flaws that allowed privilege escalation. Read about
this if its unfamiliar.)
1) Both processes know about each other and agree to the transfer. To avoid #1
and #3, we cannot force credentials on a process or allow theft of
2) The kernel is the only entity that can do the transfer based on #2. If we
open a hole so that user space can arbitrarily specify values of the
credentials, we fail on #2 and find a new way for #3.
I raised this issue with the desktop programming team as long ago as 2010. And
mentioned that because of the above analysis, we need dbus to be in the kernel
and we need the ability to have dbus activated processes to impersonate the
Back in 2012 as we started on the work for what would become RHEL7, we had a
renewed effort to convince the desktop team to go through common criteria. I
think some work started in earnest on AF_DBUS.
This is the origin and reason why the kernel dbus module is being created.