On Wednesday 29 October 2008 15:25:15 Colin Walters wrote: > On Wed, Oct 29, 2008 at 3:13 PM, Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > > 1) We've spent a lot of time on getting audit right. We can tell what > > account was logged in under and find every single application that was > > started as a result of that login. Message passing breaks this. > > True, though how interesting is the question of "what binaries were > executed" as opposed to the system having enough intelligence to > display security-relevant information? Not sure I follow your question. I am talking about /proc/<pid>/loginuid and sessionid. > > 2) There is no accountability for what actions are performed for each > > user. The audit system cannot tell who something was done for. > > Should be easy to add such auditing; actually I think we do want to > have dbus audit on system activation regardless of PolicyKit. Again I'm talking about loginuid and sessionid. > > 3) There is yet another MAC policy with no auditing of access decisions. > > Duplicate of 2)? No this is about PolicyKit being another MAC system that needs configuring. > As for the sysadmin impact, yes, there is a concern there but > there is documentation: > http://hal.freedesktop.org/docs/PolicyKit/PolicyKit.conf.5.html 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. > Anyways, I don't want to completely derail this discussion on fcap > into suid-vs-PolicyKit; 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. A user space daemon making access control decisions will not be something I want to see getting spread into things that are part of the next CC evaluation. -Steve -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
