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

Steve Grubb sgrubb at redhat.com
Wed Oct 29 21:04:43 UTC 2008


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.


> > Where's the GUI or commandline tool that lets me configure it? I may need
> > to have auditing of who changed what entry in that file. When I chmod
> > 4755 a program, I know who changed it, what the old and new values are,
> > when they did it, and what the outcome was.
>
> There's no real story on that other than "uid 0" and $EDITOR yet.
> This is basically the same as all the other OS config files.

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


> > True...but this is a discussion that needs to be had so that it can be
> > fixed. Auditing from user space is not trustworthy and that's why its
> > done from the kernel.
>
> Hmm?  SELinux userspace enforcers (dbus and X.org) are using the audit
> system; I don't think it's reasonable to say that the kernel is the
> only component of the TCB.

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.

-Steve




More information about the fedora-devel-list mailing list