Re: Security models

[Arne Babenhauserheide]

Am Samstag 06 Dezember 2008 22:17:12 schrieb olafBuddenhagen@gmx.net:
> So you have offlist discussions, have you? I feel left out ;-)

The discussion stumbled offline since Michal accidently only answered to me 
and I wasn't sure if he just wanted to avoid spamming the list with DRM 
discussions... 

> > Can that service request more memory when it runs out of memory (which
> > it can give new processes), and can it offer proper resource
> > management, so users can't harm each others performance?
>
> Not sure what you mean exactly...

What I mean is: What happens if the request the user sends to the system 
process needs more memory than what's expected? 

Does the system process just say "this is the maximum buffer length, don't 
send me more", or is tehre some way it can increase the memory it has access 
to? 

(by the way: having a user process which manages a non-restricted buffer 
should give almost the same advantages as giving memory directly to the 
server, but without the drawbacks. And it should be painless, since you'll 
most likely access the system process through a library anyway, and the 
library can handle the buffering)

> As the service in this case has information that the client is not
> supposed to see directly, it can't use client-provided resources.
> Instead, it has to get its own resources from its own parent. (Thats a
> major difference from the Coyotos model.)

What does the service do if it runs out of memory? 

> Users should never be able to harm each other's performace in this
> model. All processes created by a user are descendands of the user
> session; the total resources available to the user will be subdivided
> among them, in a hierarchical manner.

How do the system processes fit into the picture? When I as user send a 
request to a system service then the service needs memory to process my 
request. How can we ensure that I don't take all the services memory with my 
requests? Will tehre be scheduling in the sstem services to ensure that i 
can't hog it? 

> > > Indeed, this is the real threat: We can't fool the server. If remote
> > > attestation becomes commonplace, Disney will be able to deny access
> > > by our non-treacherous system alltogether.
> > >
> > > That's why we need to fight the TPM stuff teeth an claw.
> >
> > I couldn't have stated it better.
>
> Really? That's surprising -- usually you are expressing the things I
> mean to say much better than I could do myself :-)

I tend to write too long sentences, and your text just hit the nail directly. 

It depends on people understanding "remote-attestation", but in this list that 
should be a given (it wasn't targeted to a general user), and it's an example 
which just fits extremely well. 

It got me instantly :) 

Best wishes, 
Arne
-- 
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

signature.asc
Description: This is a digitally signed message part.