Hello, 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 the > 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 do > 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 > shutdown event. 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, not permissions. 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.) This implies 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 credentials. 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 gui application. 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. -Steve -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
