l4-hurd
[Top][All Lists]
Advanced

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

Re: Changing from L4 to something else...


From: Marcus Brinkmann
Subject: Re: Changing from L4 to something else...
Date: Fri, 28 Oct 2005 14:07:20 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

Hi,

nice to see you around ;)

At Fri, 28 Oct 2005 04:40:16 +0200,
"Yoshinori K. Okuji" <address@hidden> wrote:
> The recent debate in this list makes me very afraid of a possibility of 
> extreme cost which never finish in a reasonable amount of time or human 
> resource.

This is true.  But note that by evaluating EROS, we are evaluating a
system that actually exists (and which is based on precedence, namely
KeyKOS).  In contrast, there is to date no large-scale _secure_
operating system build on L4.  The L4 group has said that this is
still an area they have to examine.

So, in fact, we are exploring ground here that is definitely more
solid than the ground we have explored in the last 2-3 years.

> What makes me scared the most is security paranoia (I'm sorry for my 
> wording). 

Yes.  I have struggeled with the same question.  But please let me
explain why I think that this is critical.

First, I have always claimed that what is good for security, is also
good for robustness.  IE, what protects you against malicious code,
usually also protects you against buggy code.  It is very easy to make
mistakes if you are not paying attention.  Being paranoid forces you
to pay attention.  I have a very specific example in my capability
server design that I struggled with for a long time, until I looked at
it from a security point of view and then things became _very clear_.
IOW, being paranoid about security forces you to ignore short cuts
that just don't work.

The other reason I am interested is that this is a compelling reason
to build yet another operating system.  And we really need a
compelling reason, as on just about any other ground, we will not be
able to compete successfully with other systems like GNU/Linux, either
because we don't have the resources or there is zero interest in it
(because GNU/Linux is "good enough" or, *shudder* because Windows is
"good enough").

There is a third reason, and that is the following: I think good
security properties are a _requirement_ in the system we want to
build.  Remember we are talking about a user-extensible system.  In
the Hurd, any user could start a Mach task and not register it with
the proc server.  But yet, the proc server assigned a PID to the
process so that root could kill it.

This was the only reason that we needed to assign a PID.

If we have resource accountability, we give a user a certain amount of
resources, and then we don't care anymore.  In fact, it makes sense
then to not let the system administrator see what processes I run, how
much memory they use, etc.  The resource accountabiliy can work at a
trust domain level.  Root doesn't care if I have 2 tasks using each 10
MB, or one task using 1 MB and one using 19 MB, as long as I don't
exceed my limit of 20 MB.

But in this type of system, you absolutely must protect against denial
of service attacks.  You can't say something like: "Uhm, if a user
starts a fork bomb, I will just kill the processes, after all I have a
reserve of 5% for the sysadmin, and then I will at least know the user
ID and then I will go and slap him really hard."

Instead, you must get the foundation right and tight.  System
administrators want control.  If we want to take away the control and
give the control to the user, for user freedom, we must give the
system administrator something in return.  And this something is
increased security.

What doesn't work is that we take away control from system
administrators, and then don't adequately protect the users from each
other.

> I'm not planning to take part in design decisions, simply because I don't 
> have 
> time to read recent papers. But I wish Marcus and others would take it into 
> account that the project must be feasible and realistic.

I do.  But here is another twist: I won't start an implementation
before I don't have a realistic vision of what we are implementing.

So, in fact, from my perspective, we are currently not in the process
of dreaming up more and more stuff, but cutting away from our goals to
find something we can actually reasonably implement _and_ works.  Or
maybe it doesn't require cutting away, but just a better understanding
and some refinement.  We'll see :)

Thanks,
Marcus





reply via email to

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