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