On Tue, 2005-10-11 at 12:48 +0200, Alfred M. Szmidt wrote: > > > Extensibility is not a synonym of vulnerability. > > > > Of COURSE it is! > > > > Actually, it isn't. Me extentions to vulnerable program A do not > > affect you. > > Counterexamples: > > My hacked system may attack yours. > My hacked extension may consume resources that impact other users. > My hacked extension may corrupt my documents. You may read them, > impacting your behavior. Recent examples include web site hacks > that generated millions of dollars in payout through stock > manipulation. > > Or don't these count as ways in which I am affected? > > They don't. Just because your system attacks mine doesn't mean that > it will break the security of my system; so no harm done there.
It does today. Believe me, if I attack a system structured in the way that you advocate, I will break it. So will my son (Well, in a few months, anyway. He is busy learning to walk, but he will get around to hacking you shortly.) > If > your hacked extentions consume much cpu/memory then this is easy to > solve, quotas for system resources (I find quotas idiotic, so I don't > support them). Quotas only work if the quota mechanism cannot be compromised. I tend to agree with you about mandatory quotas. In practice, they are mostly used as a tool of social pressure by a system administrator. Sometimes this can be good on large, shared systems, but at least for personal systems I think it is a bit silly. However, *discretionary* quotas are another matter entirely. The mechanism needed to implement resource reserves is identical to the mechanism needed to implement quotas. If only to guarantee that I can kill a runaway process, I would like to have a reserve for my "program killing interface". This reserve amounts to a quota. Also, the mechanism for quota is also the mechanism for measurement of whether something has run away. Even if I do not set a limit, I need to be able to *observe* that a program is using wildly excessive memory. So: I propose that we need the *mechanism*, and it sounds like we actually agree on how it should be used. > If your extention "consumes" the NIC or something, > then there is not much one can do, a NIC isn't a shared resource. Of COURSE the NIC is a shared resource, and there is no reason not to do rate controls on how many packets a subsystem can transmit. This is absolutely no different from doing a CPU scheduler. Controlling matters on the *incoming* side, I agree, is more challenging. Once things get to the NIC, we can impose *incoming* rate controls, but there is nothing we can do about somebody saturating the physical wire (which, by the way, is the currently common remote denial of service method). This is true because (a) current routers do not provide proper resource management, and (b) flaws in the design of the IP protocol make dealing with the issue explicitly impossible. Solving this is a deeply hard problem, and well beyond what we can hope to accomplish with any one operating system. > Your last example about corrupting documents, is totally bogus, since > I can use any kind of text editor to do it, and the only way you can > prohibit this is by two ways: disallowing me to write to my files, or > disallowing other users from reading files that I have made avaiable. > Both of which are silly. Well, not really. Certainly I cannot prevent any editor from munging the file that it edits, but I *can* prevent it from munging the rest of your files, and I can do so without creating any obnoxiously invasive UI, and I can even implement a transparently versioning file system so that recovery is possible. > > What you say *can* be true, but only if the underlying system > imposes proper guards to enforce it. > > Not really, since no matter what you will add guards that prohibit me > from doing what I want. And such guards are simply not acceptable for > us. I see. That is quite a strong assertion. What evidence to you have that it is true? I look forward to reading about this design, but I don't think it has much relationship to mine. > Well, we agree pretty well on the definition of freedom. I would > add "...without their informed and competent consent", but this is > merely refinement. > > I wouldn't, since this would require users to answer a question like > `do you want to read this document?" each time they want to read a > document, since the document might contain things that are corrupt. Again, an assertion. A more productive approach would be for you to ask how this works. For example, you might ask: Guards are all very well, but if we have to ask the user every time we want to read a document, the system becomes unusably cumbersome. Can this be avoided? How? As always, I continue to look forward to constructive questions. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
