l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christopher Nelson
Subject: RE: L4-Hurd; denial of service in the memory architecture
Date: Mon, 19 Jan 2004 15:24:55 -0700

>
>On Mon, Jan 19, 2004 at 03:07:49PM -0700, Christopher Nelson wrote:
>> 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?
>
>The whole purpose of capabilities is to restrict who has 
>access to an object.  The comment is rather meant to 
>illustrate what the cap represents.

Yes, but if you are sharing a capability with an untrusted task, and
that task suddenly has the ability to impersonate you to someone else in
that it can allocate frames that count against your quota, then you have
permission leakage.  Certainly you would want that task to access THAT
memory, but you certainly would not want that task to be able to
allocate more memory against your quota.  Why does the capability to
read or write a container also permit expansion of the container?

        -={C}=-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]