OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:32 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Capability-based security and confused deputy
PostPosted: Mon Mar 23, 2020 9:43 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
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. :lol: (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.

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: Capability-based security and confused deputy
PostPosted: Mon Mar 23, 2020 10:30 am 
Offline
Member
Member

Joined: Fri Nov 22, 2019 5:46 am
Posts: 590
Gigasoft wrote:
Schol-R-LEA wrote:
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


Top
 Profile  
 
 Post subject: Re: Capability-based security and confused deputy
PostPosted: Mon Mar 23, 2020 12:20 pm 
Offline
Member
Member

Joined: Sat Nov 21, 2009 5:11 pm
Posts: 852
Quote:
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.


Top
 Profile  
 
 Post subject: Re: Capability-based security and confused deputy
PostPosted: Mon Mar 23, 2020 12:55 pm 
Offline
Member
Member

Joined: Fri Nov 22, 2019 5:46 am
Posts: 590
Gigasoft wrote:
Quote:
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 25 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group