Re: PolicyKit auditing - was Re: Fedora 11: moving to posix file capabilities?
On Wed, Oct 29, 2008 at 5:04 PM, Steve Grubb <sgrubb(a)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?