On Friday 28 October 2005 06:36 pm, Marcus Brinkmann wrote: > You put in another disk, and bill it to the customer.
I guess you are kidding. When things are really urgent, such a slow operation is not allowed. > You subdivide the user's resources into "important data" and "scratch > space". Thus, you give the user two resource capabilities (two > different "banks"). You promise your users that the "important data" > will not be revoked quickly. You don't make the same promise for the > scratch space. It works only for people who are familiar with computer and have a lot of time. It is not acceptable for busy people to consume precious time to decide if each piece of data is important or not. Probably they would just insert all data to "important data". > I revoke the network capability for her session. This is too violent. What if she does not want to hide everything? For example, if she wants to check a note from an internet cafe? > If she doesn't remember her password later-on, you will have to kill > the session anyway. She might be able to remind herself of the password when she comes back and sits down in front of the computer. This is called "associated memory". > But here is the important thing: Of course you _could_ also implement > backdoors for the administrator into the user sessions. This option > is there. You can always make a system less secure by introducing > more capabilities. > > The important thing is that you can also not do it, and choose the > "paranoid" scenario. The reverse is not possible. An insecure system > is insecure is insecure. I know. What I meant was that a supervisor is required or too useful to be disabled in many situations. I can think of many more examples (e.g. system-wide backup), so I bet that nearly all users would choose to have a supervisor with exchange of a certain amount of security. This is one reason why I feel that security paranoia is too expensive, because very little people use such an extreme configuration. Okuji _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
