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