l4-hurd
[Top][All Lists]
Advanced

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

Re: Challenge: Find potential use cases for non-trivial confinement


From: Bas Wijnen
Subject: Re: Challenge: Find potential use cases for non-trivial confinement
Date: Wed, 3 May 2006 14:47:31 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Wed, May 03, 2006 at 02:18:12PM +0200, Pierre THIERRY wrote:
> Scribit Bas Wijnen dies 03/05/2006 hora 14:06:
> > An example of this is that Linux prevents mounting a floppy, even if
> > the user has full access to /dev/fd/0.
> 
> Which I think is nonsense. If you don't want me to access it, don't give
> me access to it in the first place.

It was meant as an example of the system putting useless limits on what the
user can do.  In other words, I fully agree with you. :-)

> > So it seems this requires CPU scheduling donations.  In fact, I
> > suppose that would be possible, too: The students trust the teacher
> > enough to give their scheduling capability, so that can be used by the
> > service.  Of course they give it in a way that they can revoke it
> > later.
> 
> That doesn't address the DoS vulnerability.

It does.  The student gives the service a scheduling capability, which it uses
to start the secret program.  So that instance of the program runs on the
student's scheduling resource.  The service itself doesn't.  The only thing
the student can do is revoke the capability, which will stop his own instance
of the program running.

> And I don't think that's sensible: a student should give scheduler
> capabilities to a service running for all students to be able to run the
> service for itself.

No, this is not the case.  The student gives the capability only to run the
program for himself, not for the other students.

> That seems very complicated when compared to the constructor pattern.

Complicated, maybe.  But the case isn't something that would frequently happen
either, so it's not a problem if it's a bit complicated.  In practice
(currently), there are no scheduling quota.  There is the option of a
DoS attack by the student.  This is solved socially, by banning the student
from the computer if they find out that such things are happening.  That works
quite well as a solution. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

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