On Tue, Nov 24, 2009 at 11:35:13AM -0500, Matthias Clasen wrote:
> PolicyKit itself is not running anything. It is just answering the
> question of a mechanism: 'is X allowed to do foo ?'. It would make more
> sense for the mechanisms that use PolicyKit to log privileged actions
> that they do or deny to do.
That makes sense. However, I can see strengths in both approaches.
A good analogy is PAM, particularly the "auth" section, which does basically
the same thing¹ as PolicyKit. There, you get logs both from the application
itself and from PAM directly.
There are four particular strengths I see in logging at the PolicyKit
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.
2) Log levels and debugging are easier to admin because there's a central
configuration (and PolicyKit already has config files). If I want to
turn on more authentication
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.)
Also, since this is a security/auditing issue, I thing it's never wrong to
error on the side of more logging.
I absolutely agree that client applications should also log their
elevated-privilege actions.
----
1. In fact, a PAM-backed authority for PolicyKit might be interesting and
useful -- but there's a tangent.
--
Matthew Miller <mattdm@xxxxxxxxxx>
Senior Systems Architect
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
