Capability-based security and confused deputy

[eekee]

I wonder how Plan 9's auth server deals with this. Actually, I don't think it does. If you don't trust a client program or machine, don't let your auth server grant it privileges. I can't really say more or properly reply to Schol's questions because Plan 9 documentation results in Confused Sysadmin. (You have to understand the source code.) Maybe I shouldn't have mentioned it with my patchy knowledge, but I wanted to highlight its architecture of physical separation. In a traditional Plan 9 system/network (same thing), the credential-checking deputy doesn't share a physical machine with anything else, and neither does the file store.

[PeterX]

The process granting the capability doesn't need to keep a list of the tokens it has granted; only the process holding the token has that information, and the token can be passed to a different process without any intervention from the grantor. While this itself opens up a new way for the Confused Deputy problem to arise (if process A grants B a token, and B passes it to a process it shouldn't, then A becomes a Confused Deputy), but the system is supposed to have ways of checking for that - though I would have to re-read those papers I mentioned to recall how.

No, why would you think so? It shouldn't matter to A whether invocations come from B or some other process. In no case should the meaning of an invocation change such that an unintended resource is now being accessed. Thus, process B can not cause anything to happen by duplicating a token into another process that it couldn't also do by acting as a proxy for requests coming from the other process.

You're probably more an expert than myself. But it seems to me that hindering an instance (for example process) to give a key to any other instance (or at least to some instances) can increase security. Don't you think so?

Greetings
Peter

[Gigasoft]

But it seems to me that hindering an instance (for example process) to give a key to any other instance (or at least to some instances) can increase security. Don't you think so?

In a capability system, this is already solved. The only way to pass a capability to another process is by possessing a capability that allows inserting handles into the other process. This typically means that the first process spawned the other, or they have established a communication channel that allows the transfer of capabilities. Being able to transfer a handle or not has no effect on security, nor does it impact the ability to record an audit trail in the case of mischief.

For example, let's suppose an attacker wants to write a malicious word processing application. It can spawn as many other processes as he wants and transfer file handles, thread handles, window handles etc. around among them, but in the end it still can't do anything with this beyond trashing the files that the user tries to save, or leaking information from one opened document into another. Can it leak information or grant any sort of access to the user's files to the attacker himself? No, because it has no way of establishing a communication channel with the attacker.

[PeterX]

But it seems to me that hindering an instance (for example process) to give a key to any other instance (or at least to some instances) can increase security. Don't you think so?

In a capability system, this is already solved. The only way to pass a capability to another process is by possessing a capability that allows inserting handles into the other process. This typically means that the first process spawned the other, or they have established a communication channel that allows the transfer of capabilities. Being able to transfer a handle or not has no effect on security, nor does it impact the ability to record an audit trail in the case of mischief.

For example, let's suppose an attacker wants to write a malicious word processing application. It can spawn as many other processes as he wants and transfer file handles, thread handles, window handles etc. around among them, but in the end it still can't do anything with this beyond trashing the files that the user tries to save, or leaking information from one opened document into another. Can it leak information or grant any sort of access to the user's files to the attacker himself? No, because it has no way of establishing a communication channel with the attacker.

I didn't know that. Thanks!

This is important information for my planned kernel.

Greetings
Peter