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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
