Credential passing

There's probably some good technical reason why the idea below wouldn't work well (since it is too obvious to not have been proposed/implemented already), but at first glance it looks like the kernel should encapsulate entirely all process-related credential passing.

At message submission time, it would "attach" the full set of credentials (which actually depend on the security models active in the kernel, e.g. capabilities, SELinux contextes, kernel-keyring-assisted crypto signatures, etc). Maybe allow a flag that signals "no credentials need to be sent" (or the inverse). This closes most (if not all) race windows re. credential passing.

At message receiving time, the kernel would check the credentials of the receiving process, and if it has the appropriate ones (security modules might want to filter this, for example), and the message also has the credentials required by the receiving side, deliver it.

At no moment is the full, raw, credential set exposed to userspace. Not even for querying. Thus, the details of the credential set do not become stable kernel/userspace ABI.

The devil is to provide a generic ("functional") set of credentials that the receive side can request to be checked (by the kernel) against the message. THIS set of functional/generic credentials would become a stable kernel/userspace ABI, of course. It has a possibly steep cost, but it can deliver better usability of the whole interface, it avoids layering violation, and it seems to be amicable to the security model of the kernel (use of security hooks to implement different security modules, etc).

Meh, this possibility has likely already been dissected in the monster thread. Will have to read it now.