Subject: RE: [rddp] security doc - Definition of Trust

From: "Jim Pinkerton" <[email-masked]>
Date: Tue, 22 Jul 2003 16:49:31 -0700

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-masked]] 
Sent: Monday, July 21, 2003 6:13 PM
To: Jim Pinkerton
Cc: [email-masked]
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-masked] - http://asomi.com/

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 22 Jul 2003 19:12:30 -0500

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

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

> "Privileged Resource Manager – the component responsible for managing 
> 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 

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.

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp