> Going back to your earlier statement yesterday it seems your argument boils down to we should write code properly and rely on userspace to police itself.
I think I could go along with that summary. Badly written code can be exploited whether it is in the kernel (including SELinux, as Brad Spengler has shown) or in user space. And the system administrator is responsible for installing both kernel and user space, and (it seems to me) should worry more about whether the mechanisms work and are well audited than exactly at what level they are implemented. (Speaking as someone who often writes non-security-related code which can live on either or both sides of the kernel/user space dividing line.)
>It also ignored the fact that the set of actions that policykit is policing and the objects it is protecting are completely disjoint from the objects that the kernel protects. policykit isn't going to provide you any sort of access control to the things under the hood.
Could you please give an example of what you mean there?
> From what I can tell any "client" can send any message that a user is allowed to a policykit enabled "mechanism".
I thought there was a school of thought that claimed that associating privileged actions with users, not with applications was a sound thing to do, but I am not knowledgeable about the subject to have an opinion about whether you or they are right.
> So in theory I could exploit an application and have the user think he's typing in his password to say change the system time but instead send a DBUS message to perform some other action.
Surely anti-spoofing password entry mechanisms are an orthogonal problem? For example, just an example, when requesting the password the privileged module could require some unspoof-able sequence (like Ctrl-Alt-Del in Windows) which brings up the password box, complete with a description of the action.