RE: L4-Hurd; denial of service in the memory architecture

[Christopher Nelson]

>"Christopher Nelson" <address@hidden> writes:
>
>> A container\_t is, for all intents and purposes, a 
>hurd\_cap\_t.  If a 
>> container is shared with another task, the second task may allocate 
>> frames which count against the container's owner's total allocated 
>> pages.  This must be used with care.
>> 
>> 
>> ---------
>> 
>> This sounds like a denial of service attack waiting to 
>happen.  There 
>> should be a way to forbid another task from using this capability 
>> against the owner.  Has more thought been given to this scenario yet?
>
>I think the word "share" is used in two different meanings. I 
>also found that a little confusing when I read it. This is how 
>I understand
>it:
>
>If you copy the container capability to another task, that 
>task can allocate pages into the container. So don't do that 
>with tasks you don't trust. But the normal way of "sharing" 
>means that the owner allocates some pages, and lets another 
>task *access* the pages. Then the other task is not allowed to 
>add any new pages pages into the container.

>From reading the design doc for the VM, it appears that sharing the
container with another task gives it the ability to allocate additional
pages into the container under the guise of the owner.  I don't see why
this should ever need to happen, and it sounds like a serious security
hole.  Another thing which bothers me about this implementation is the
trust aspect.  Why would you ever trust ANY other task?  It seems that
one of the founding precepts of Hurd is to have multiple, mutually
untrusted servers talking to clients which don't trust each other.  Why
do we suddenly trust tasks with whom we need to share containers?  

        -={C}=-