Hello everyone, We've been discussing the options of restricted storage a bit. These "restrictions" are from the supplier of the storage. It is possible that there are different restrictions for different suppliers (that is, for the parent, and for the parent's parent, etc). I'll say some things which I'm pretty sure about first: - There are two types of restricted storage: read-only, and no-access. Both types do not provide access to the capabilities of the running program. - When a user starts a sub-Hurd (or debugs a program in some other way), it must be impossible for the program, or any of the programs it spawns on its own storage, to become restricted. - If a user debugs a program (in a sub-Hurd or otherwise), the program must not be able to detect this (except through contact with other programs which can see it, but they are not likely to have capabilities to them). A program's behaviour must thus be completely orthogonal to the fact if it's being debugged.
I think Jonathan does not agree with the last two points. These are design choices, and he makes different choices. That's fine. I'm just saying that these are the choices I expect the Hurd to make. Now then, on to the actual content of this e-mail. So far, there have been two examples where restricted storage seemed needed: Running a competition, and ping. First of all, in all cases the problem can of course be solved by letting the party who wants to keep the secret pay for the storage. This however is in some cases the wrong party, which usually leads to DoS opportunities. Then again, this is not always a problem, because there is a limit on the amount of storage that is used, for example proportional to the number of users on the system (if the number of simultaneous uses by the same user is limited to some number). In such a case, it may be acceptable to let the secret-keeper pay for the storage. I'm particularly interested in ping at the moment. We can say that we'll use the "limited number of simultaneous uses per user" approach, but we would really prefer to have no limits on this. So in that case we will need read-only storage. Marcus stated that because the network driver is provided by the system, it can simply take some user storage and give it back later. In other words, the system can choose to use opaque (or read-only) storage, even if it doesn't allow this functionality to normal programs. This last statement is of course true. However, the one before it may not be. Assuming that we have a good driver framework, it is very well possible that I plug in my own network card on a usb port, which connects the machine to a couple of other computers. Suppose this happens on a university, and some students arrange this setup so they can all use those other computers. Since I'm behind the terminal with the network card, I own the usb bus and provide a network driver for my card. The other students will tell their shell that they want to trust my driver and use it for communicating with the other machines (not a lot of trust is needed for that, but they must be explicit about using my driver, of course). In that case, my driver will be unable to use restricted storage if the system doesn't provide that functionality to "normal" programs. So then there are a few options: - My driver doesn't support ping, or only in a limited way, so it uses "constant" storage (where this "constant" is a function of the number of users on the machine). - My driver fully supports ping, and is vulnerable to DoS by its users (which are all trusted (in a real-life social way) students, so this might be acceptable). In both cases though, I cannot use the "normal" network driver, because that uses (at least) read-only storage, which is unavailable to this one. So there is a need for two different driver programs depending on if it is system installed or not. This is unfortunate. There is one very important point though. I think those restrictions can easily be implemented in the user session. This means that we can just build a system with no support for restricted storage, and add it if we find that we did need it after all. However, Jonathan doesn't seem to agree. At the moment I still think he doesn't quite understand what I mean. However, if he does and is correct that it cannot be added later, we would need to decide this before building the system. So Jonathan, I'm particularly interested in your answer to the question: Do you agree that restricted storage (in the way I want it, so non-recursive) can be implemented later, in the user session, or do you still think this is very hard? If you think it is very hard, why? And related, do you think there is anything wrong with non-recursive restrictions (so that the process starting a sub-Hurd can always read and modify any storage inside it), in the sense that it makes things impossible which should be possible (considering our objectives)? Thanks, Bas Ps: I'm not only interested in Jonathan's opinion, anyone else who has something to share please reply as well. :-) -- 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
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
