Hi, nice to see you around ;)
At Fri, 28 Oct 2005 04:40:16 +0200, "Yoshinori K. Okuji" <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
