Scribit Marcus Brinkmann dies 08/01/2007 hora 04:58: > Pierre, no matter how often you ask this question, the answer will > always be the same: "If anything, then only the license." I can only > build a system that is secure by default. You have to break it > yourself. That is true no matter what.
The problem is, I don't see where your proposal makes the system any more secure than with the indiscriminate use of opaque memory. Your proposal makes it more complex, which is known to make a system less secure, in the sense that the more simple it is, the more reliably we can implement it correctly and find it's weaknesses. > I notice that there are quite a couple of such ideas that you keep > bringing up again and again, and the answer is always the same, but > somehow I am not getting through to you. Do you have the same > impression? Well, sometimes you answer my questions by "It's not the real question", which leaves my actual question unanswered. I may also be bringing up ideas that I implicitely understood in your emails (and that I could have wrongly infered from their explicit content). > And do you have any suggestion how we can work this out to avoid > endless repetition? Be clear on the issues that we try to resolve. So I'll ask the question again, but as clear as possible: The mechanism of opaque memory has been used in scientific litterature (could someone tell if it has already been used in deployed systems?) to achieve POLA at a very high level, even in system components, while retaining very good performance, by avoiding copy accroos protection boundaries, and enabling more secure designs, by naturally adding resource accountability and rendering services resistant to classical denial of service attacks. You claimed that it could be used to implement policies you consider to be security threats. What harmful policies can be achieved through this mechanism that cannot easily without? How does your proposal protect users from these threats? Clearly, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
