[cap-talk] Resource exhaustion - a language level issue?

Sandro Magi smagi at higherlogics.com
Tue Oct 9 14:39:30 EDT 2007


Jed Donnelley wrote:
>> I'm not sure. A system vulnerable to denial of service (DoS) attacks
>> violates isolation guarantees;
> 
> Why do you believe so?  A system that has been impacted by a
> denial of service attack is not available (by definition),
> so the isolation is perfect - isn't it?

I'm talking about isolation between two entities on the *same* system,
not different systems. If subsystem A is perfectly isolated from
subsystem B (no capability path between them except via the kernel),
then an attack in B should have no visible effect in A. With a DoS, this
is not the case.

> "Operating systems account for memory consumption and
> allow for termination at the level of individual processes.
> As a result, if one process consumes too much memory, it
> can be terminated without damaging the rest of the system.
> This same capability can be useful within a single application
> that encompasses subtasks."
> 
> and I would go beyond "can be useful" to 'seems to me
> necessary' - just as it is at the OS level.  If trust
> boundaries are going to be enforced at the language
> level then all the mechanisms required at the OS level I
> believe are needed at the language level.  To even
> distinguish a "language level" seems a bit odd as the
> enforcements that one associates with a trusted computing
> base needs to be there at the language level if trust
> boundaries are to be trustworthy.

Yes, and in most languages such primitives are not there, which is why
languages are still vulnerable to resource exhaustion attacks. There has
been some work on adding process-like primitives to languages [1], so
that OS-like isolation and accounting are possible within the language
itself; the PLT Scheme paper calls these "custodians". Most such
implementations don't seem to have gone beyond limited deployment, or
proof-of-concept however.

I'm very interested in pointers to any projects that I haven't listed in
[1] or here.

Sandro

[1] http://www.eros-os.org/pipermail/e-lang/2007-August/012206.html


More information about the cap-talk mailing list