RE: security doc - Definition of Trust

 

You statement:

 

> For example, RDMAP/DDP could be implemented as a user-mode library

> running on top of a traditional stack. If it only exposed the 

> applications

> own memory then there is no need for a "Privileged Resource Manager".

> The looser rule, that the local interface grant the RNIC Engine no

> authority that the caller itself did not have, is met by simply

> running within the process.

 

Is exactly where you need a resource manager. There are fixed resources
available, presumably (no-one has invented an infinite memory computer
yet...) For example, on many systems random user can launch any
user-mode code they wish. Thus anyone running on the system can attempt
to be greedy and grab as much RNIC resources as possible, thereby making
a DOS attack possible against other user mode clients, so long as they
get the resources first. You could certainly argue you don't care about
this attack - but it doesn't mean you shouldn't have a clean way of
modeling the attack and showing those that care about this type of
security issue how to address the attack.

 

 

On another issue, I don't understand your statement of

 

" The descriptions of the Privileged Resource Manager

presume a multi-process Unix/Windows style OS dealing with

an RNIC Engine implemented primarily in hardware and/or

fully enabled (i.e., kernel) memory space. That's certainly

99.99 whatever % of the world, but it isn't everything."

 

Where in the document does it make that statement? The document
specifically defines it as:

 

"Privileged Resource Manager - the component responsible for managing
and allocating resources associated with the RNIC Engine. The Resource
Manager does not send or receive data."

 

It makes no statement about whether an operating system is present,
whether an RNIC is in hardware or software, whether the resource manager
is a procedure or a separate process, etc. It was meant to be as generic
as possible. If we simply clarify the text, does that help? Maybe
something like:

 

"Privileged Resource Manager - the component responsible for managing
and allocating resources associated with the RNIC Engine. The Resource
Manager does not send or receive data. Note that whether the Resource
Manager is an independent component, part of the RNIC, or part of the
application is implementation dependent. If a specific implementation
does not wish to address security issues resolved by the Resource
Manager, there may in fact be no resource manager at all."

 

 

 

Jim

 

 

 

-----Original Message-----
From: Caitlin Bestler [mailto:[email protected]] 
Sent: Monday, July 21, 2003 6:13 PM
To: Jim Pinkerton
Cc: [email protected]
Subject: Re: [rddp] security doc - Definition of Trust

 

 

On Monday, July 21, 2003, at 07:58 PM, Jim Pinkerton wrote:

 

> On the idea of removing the privileged resource manager, I guess I'm 

> unclear on the advantage of it. It's just a reference model to help 

> clarify issues. There are no MUSTs anywhere. Using the text as you 

> describe basically collapses the functionality into the RNIC. To me 

> one of the intentions of the paper was to specifically slice up the 

> security issues into more detail to better explain the issues. How you


> implement it is your business though.

 

I'm trying to be inclusive of all possible implementations.

 

For example, RDMAP/DDP could be implemented as a user-mode library

running on top of a traditional stack. If it only exposed the 

applications

own memory then there is no need for a "Privileged Resource Manager".

The looser rule, that the local interface grant the RNIC Engine no

authority that the caller itself did not have, is met by simply

running within the process.

 

At the opposite extreme, I have worked with system buses where the

driver was allowed to directly DMA into a user map. (Not that anyone

has done anything like that *recently*, but ideas have a way of

cycling back around. Who knows about 3 years from now?).

 

So I'd like to recognize that there are multiple ways of ensuring

that an RNIC Engine does not violate the host system's security

rules. The descriptions of the Privileged Resource Manager

presume a multi-process Unix/Windows style OS dealing with

an RNIC Engine implemented primarily in hardware and/or

fully enabled (i.e., kernel) memory space. That's certainly

99.99 whatever % of the world, but it isn't everything.

 

Perhaps if the principle were established that some form of

access validation would be required, and that it would likely

be required to start from a single root authorizer. The Privileged

Resource Manager described could then be given as an example.

 

 

Caitlin Bestler - [email protected] - http://asomi.com/