PolicyKit auditing - was Re: Fedora 11: moving to posix file capabilities?

[Colin Walters]

On Wed, Oct 29, 2008 at 5:04 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> On Wednesday 29 October 2008 16:52:48 Colin Walters wrote:
>> > Not sure I follow your question. I am talking about /proc/<pid>/loginuid
>> > and sessionid.
>>
>> Oh.  Well, if your application uses PolicyKit there are *two*
>> programs; the privileged mechanism, and the unprivileged application.
>> The unprivileged application of course maintains the loginuid.
>
> Which is a problem. We have no way to connect the session ID for the backend
> with the frontend. That means we can't make a killall mechanism that nails
> everything in a login session.

Conceptually the mechanism isn't part of the login session, it's OS
infrastructure that runs in userspace, just like libvirtd, iscsid[1]
or HAL.  In particular the same mechanism process can be reused by
multiple uids, just as multiple uids can share a page cache entry in
the kernel or enumerate devices from the HAL daemon.

> No...we have a handful of apps that audit changes to trusted databases.
> password and adduser are two examples.

Sure...but that's a tiny minority of files for the core OS; at least
looking at "ls /etc".  Don't get me wrong, I think it would make sense
to have a frontend tool but I can't see how the lack of one would be
considered a blocker.

> I have to be able to tell the audit system to include or exclude events from
> certain users. That would mean a user space access control daemon would have
> to download and enforce audit policy. Nothing else does that because all the
> necessary process attributes are maintained across the exec model and the
> kernel can access it all.

How Policykit should interact with auditing sounds like something to
bring up on the PolicyKit list; like I said before I think we do want
at least auditing of dbus system activation and that would be a use
case for userspace audit policy loading.

[1] Why the heck is my F9 desktop running iscsid?