Bug 541040 - Enable logging in PolicyKit (for policy changes and for authorizations.)
Enable logging in PolicyKit (for policy changes and for authorizations.)
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: polkit (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-24 14:36 EST by Matthew Miller
Modified: 2014-01-21 01:15 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-15 16:37:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2009-11-24 14:36:51 EST
One of the important features of sudo is its ability to log elevated-access
actions to syslog. Userhelper similarly logs actions taken as other (usually root) users.

PolicyKit serves a similar function (in a nice, modern way), but doesn't seem to log anything.

Additionally, since PolicyKit's LocalAuthority is already monitoring for new pkla files, it's in a good place to log changes to policy -- something we don't have with sudo or userhelper/PAM.

So, there's two aspects.

First, PolicyKit's LocalAuthority monitors its configuration directories for changes. When a file is added, removed, or changed, a auth.warning message should be logged. Details of the change should be logged as well, but at a lower level (auth.info, probably).

Second, when PolicyKit grants authorization for a specific action, it should log that event. The basic action should be authpriv.notice (in keeping with sudo and userhelper). This would look something like:

  polkit-1[1111]: allowing action "org.libvirt.unix.manage" for process 222 for identity "unix-user:mattdm"

or 
 
  polkit-1[1111]: DENYING action "org.libvirt.unix.manage" for process 222 with identity "unix-user:mattdm"
  
(Or similar -- details, details.)

A more verbose log level (authpriv.info, maybe) should log the authentication type requested (auth_admin, auth_self).

And a yet-more-verbose level (authpriv.debug) should log Authority-specific configuration/diagnostic information, like the pkla or policy file from which the authorization came.

There are four particular strengths I see to logging this information at the PolicyKit level rather than just the client application level.

 1) Existing applications don't need to be changed, and new applications
    don't need to be counted on to do the right thing. Appropriate logging
    just starts happening. In general, having logging of security-elevation
    events in the lowest-common-denominator piece of code keeps important
    information from getting lost due to insufficient logging in a calling
    app¹.

 2) Log levels and debugging are easier to admin because there's a central
    configuration (and PolicyKit already has config files). If I need to
    turn on more authentication debugging, I don't have to hunt down   
    app-specific options.

 3) Log messages are automatically consistent between programs, making
    analysis and monitoring much easier.

 4) PolicyKit is in a position to log more about the decisions it makes
    than is (or should be) exposed to the client application. This can be
    particularly useful for debugging but may also be useful for auditing.
    If a user was allowed access for a certain reason, and that reason
    turns out to be something they shouldn't have access to but do,
    we can know to investigate.

Client applications should also be encouraged (perhaps even in the PolicyKit documentation) to use syslog to log their elevated-privilege actions -- just as PolicyKit knows details about the authorization that the application can't, the application knows details about what it's doing with the authorization that PolicyKit just doesn't care about.

Since this is a security/auditing issue, it's never wrong to error on the side of more logging.


----
1. This bit paraphrased from a comment from Seth Vidal.
Comment 1 Matthew Miller 2009-11-24 14:45:36 EST
I should add that the work to do this is both not terribly complex and not
terribly thrilling. My daughter is at home with the swine flu and I'm watching
her, which isn't, what with the lethargy and all, a terribly demanding task. So
I may have time to work on a first cut. 

Unless someone _else_ is really excited about this and wants to beat me to it.
:)
Comment 2 Matthew Miller 2009-11-24 21:31:22 EST
So one thing that occurs to me as soon as I start poking at the code -- it's 
relatively easy to have it emit a log message when a policy file is changed, 
but this is largely useless because there's no way to verify the policy
state _at startup_.  
   
So I think it's probably better to leave that aspect to more traditional
tools for monitoring file changes.
Comment 3 Steve Grubb 2009-12-02 16:17:15 EST
I should add that on Linux, the only authoritative access log is the audit system. This is because syslog has no integrity guarantees. So, any access decisions should probably go to the audit system which requires CAP_AUDIT_WRITE. Pam already logs to the audit system.
Comment 4 Matthias Clasen 2010-02-15 16:37:28 EST
Logging has been added in polkit 0.96, which will appear in F13.

Note You need to log in before you can comment on or make changes to this bug.