Re: The Perils of Pluggability

[Jonathan S. Shapiro]

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