> With that same reasoning you can't protect an application layer framework solely at that layer. If you think that the way to secure usespace is by properly auditing all userspace code to make sure its all ok then we'll have to disagree.
Perhaps you did misunderstand me then. I certainly wasn't talking about auditing all of user space. The whole point of PolicyKit is to restrict the trusted code base which needs to be audited to a minimum, particularly by sharing a lot of code which is typically duplicated in e.g. setuid applications. And it uses kernel protection mechanisms to achieve that - like user separation, with the user the module is run as privileged and the other not. However these are standard POSIX mechanisms, not "homebrew" Linux ones.
> It will not protect you if there is a fault in the "mechanism" that is using policy kit. If you find a way to send a bad DBUS message which allows you to hop the policy kit check through some exploitable code then you can still run.
Perhaps it is simpler to talk about a malicious user of the PolicyKit mechanism? But how does this differ from a malicious user space binary gaining privileges by exploiting a hole in SELinux code in the kernel?
> If you bind an action to a user any policykit enabled program can authenticate and send a related message to a mechanism regardless on whether or not it is supposed to send that message type.
Indeed - my thought regarding spoofing and the trusted path was that this is somewhat mitigated if the policy module can unspoofably communicate back to the user what it is proposing to do at the same time as it asks for the password, so that if a malicious application running as the user has requested "overwrite /etc/passwd" the user will be reliably told that by entering their password they will cause /etc/passwd to be overwritten. I don't think that PolicyKit can currently do this in an unspoofable way, though I think it is designed in such a way that it can be added.