RE: security doc - Definition of Trust

I think your point at the end is a good one:

> Virtually all implementations *will* be in hardware and/or kernel based. 
> When the RNIC engine requires *special* privileges then a Resource Manager
> is indeed a requirement.

Thus using language that maps well to that environment while not restricting in any way the implementation seems appropriate. That was the approach intended by the authors. If you note, in the text we tried to be extremely careful to define terms. I think part of the issue here is you aren't applying the strict definitions in the paper. You're adding your own baggage as to what "privileged" means, and whether that applies to hardware or software implementations.

From the ID, there is never a mention of user-mode verses kernel mode, other than in an example (or at least it was not intended, and we'll fix it if there is!). Same for what is done in hardware vs. software - there is never a distinction made - both are implementation issues. We dealt only with "Privileged" and "Non-Privileged".  In the context of an application, the contrast was defined as:

"The Privileged Application is partially trusted. It is assumed that the Privileged Application will not intentionally attack the system (e.g., it is a kernel application), although it may be greedy for resources."

"A Non-Privileged Application's capabilities are a logical sub-set of the Privileged Application's. It is assumed by the local host infrastructure that a Non-Privileged Application is Untrusted. All Non-Privileged Application interactions with the RNIC Engine that could affect other applications need to be done through a Trusted intermediary that can verify the Non-Privileged Application requests."

Further in the specification, the Privileged Application Data Transfer Interface is defined to be a superset of the Non-Privileged Application Data Transfer Interface:

"Privileged Data Transfer Interface - A superset of the functionality provided by the Non-Privileged Data Transfer Interface. The application is allowed to directly manipulate RNIC Engine mapping resources to map an STag to an application data buffer."


Not sure if this helps or not, but I wanted to make sure you understood the intention of the authors. We tried very hard to be generic - I think the biggest issue I see here is you believe using the word "privileged" implies something, but the document does not appear to support your assumptions?


Jim




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


On Tuesday, July 22, 2003, at 06:49 PM, Jim Pinkerton wrote:

>  
>
> Your 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.
>
>  

The "RNIC" has limited resources, because it is software running
*within* the context of the user process.

Typically a Privileged Resource Manager is required because the
RNIC is hardware that executes in a context where the OS cannot
veto its actions. On most platforms, hardware must be trusted.

That is different than the common "OS bypass" model, where a
user-mode library interfaces  more or less directly with the RNIC.
You are quite correct that under such a model, a Privileged
Resource Manager (or some equivalent) is required to validate
the resource authority of each of these libraries.

This is mostly a language point. The security draft should
deal with all implementations. It is of course totally
appropriate to point out that typically the RNIC Engine
must operate with system-wide privileges. And that requires
the existence of a Privileged Resource Manager.

But you *can* implement the protocol without assuming system-
wide privileges. It may even be possible to have a Java Applet
client. It would be silly, but it would be a legal client.

>
>  
>
> 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.

The concept that access to resources needs privileged control assumes
that the RNIC is operating in a context that is at least partially
something other than normal user software.

> 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."
>
>
>

The real distinction is not whether an implementation *wants* to address
security issues, it is a question of whether the implementation needed
to be placed outside of the normal OS-specific security mechanisms
(i.e., it is running in hardware and/or the kernel). Does the RNIC
engine require privileges that a simple user process would not have,
such as accessing memory in multiple user maps?

Virtually all implementations *will* be in hardware and/or kernel
based. When the RNIC engine requires *special* privileges then a
Resource Manager is indeed a requirement.