On Tue, Nov 08, 2005 at 03:50:38PM -0500, Jonathan S. Shapiro wrote: > [Bas: When I got to the bottom of your note, I realized that I should > have started this from another direction entirely. I want to send out > these comments anyway, but I suggest that we need to proceed through the > design from the bottom and work up in order to have a clearer > discussion.]
Sounds good. > > You're saying that as if we aren't this distributor. ;-) Of course we shall > > not be the only distributor, but I think we don't want others to accept this > > burden either. > > That is not your decision to make. It is the distributor's. It's our decision as well. The GNU project is a political project, not a technical one. The implementation is mostly technical, but we should keep the political goals in mind. Anything which works against them should be rejected. > > The GNU project is meant to allow people the freedom to change software. > > If a distributor will only support unchanged versions of the system, he is > > really setting up a barrier against changing it. We don't want to > > stimulate that kind of thing. So as supporting it has this as a potential > > side effect, a cost would be that we are losing our principles. > > It is true that the GNU project allows people to change their software, and > protects their right to do so. But it is also true that a distributor can > offer things **in addition to** software, and these offers may be > conditioned on *not* changing the software. They can do that, but it would be against the spirit of the GNU project. Therefore, the GNU project may (or even should) make it hard for them to do this IMO. > For example, I can ship you a completely GPL system, and I can offer you a > warranty and/or support contract on that system. You are free to change the > system, but I am free to say "the warranty and/or support contract applies > only to the configuration that I sent you." > > GPL has *never* required that support providers be willing to support > arbitrary code changes by the customer. The philosophy encourages that the > support provider should be reasonable and flexible, but it doesn't require > it. Indeed, there is no legal requirement for any of this. But when we implement a GNU kernel, we should not only live by the written rules, but also by the philosophy. And that may include limiting technical options which have no other objections against them. (I'm not sure if that applies here.) > GPL also does not say "you, as the user, must be changing your system all > the time". It says that you *can*, not that you *must*. Of course. A requirement to keep changing would be absurd. > From the user perspective, it is very likely that I would prefer to pay for > support, and that as part of this deal I understand that there are freedoms > that I will refrain from exercising in order for meaningful support to be > possible. Many users also prefer a system that can play the latest games but spies on them over a secure system that doesn't run those games. That doesn't mean we must give up and all use Windows though. What I'm saying is that what the user wants isn't always holy. In some cases, we should try to convince the user that he's wrong and that our approach is better. These are always philosophical matters. > > Compared to a system where the user can debug any program that he starts > > (this does not include programs which take external capabilities such as > > su), assuming that there is a way to make debugging impossible does cost > > the user control. Not over the content, but over the executable which > > cannot be debugged. > > Nobody has required the user to execute the program that declines to be > debugged, in the same way that nobody requires the user to execute Windows > after buying a laptop. Please explain the distinction between these two > examples. The difference is our support. The first is something we can prevent by not making it possible in the OS. The second is something we cannot influence at all. > > > What you are really arguing is that the two parties should not be able > > > to jointly negotiate middle positions on control according to their > > > needs and requirements. > > > > I'm not arguing for that, I'm just claiming that it follows from not > > supporting those chips. > > Yes. If we do not support these chips, then we reduce all control > negotiations to the choices "all" or "nothing". If we *do* support these > chips, then a much wider range of possibilities is opened. > > But what you *appear* to be arguing is that two competent parties should be > *prevented* from forming these relationships, and to ensure that they cannot > do so we should not support the chips. I'm not really sure if I'm in favor of the argument, I'm more writing down what I'm currently thinking. I didn't reread what I wrote before, but it can very well conflict. ;-) Indeed, I am saying that we want to prevent these relationships, and therefore we should not support the chips. This is because of the risk: If checking for unchanged code would become commonplace, this effectively destroys the user's freedom to change it. Because what's the use of changing code if doing that makes half your system stop working? It may happen anyway, or it may not happen even if we do support the chips. But there is a chance that it only happens because we support the chips. I don't want to take that risk. > > > This sounds like exactly the sort of restrictive policy that we should > > > be trying to avoid. > > > > You say that like it follows from a design principle. Which one is that? > > I'm interested because I want to know if I agree that we want it. > > The principle is a social principle, not a technical principle: if two > competent parties wish to engage in a feasible relationship that does not > harm third parties, it is not appropriate for me to decide by fiat that they > should not, nor is it appropriate for me to engineer into my designs a > decision that would have the effect of preempting their freedom. I agree with that, but only insofar it doesn't conflict with other principles. I think in this case it does. This is exactly the difference between open source and free software people I think. Open source advocates would probably say "who cares about politics, let's make everything possible". I think we should care about politics, and that making this possible may have the effect of restricting end-user's freedoms in the long run. > > > The metaconstructor (and, for that matter, the constructor) is part of > > > the TCB. > > > > I know that the meta-constructor is. But I'm creating an object, pretty > > much like any other process, which happens to work like the > > meta-constructor. But when someone asks the meta-constructor if it > > created one of its "constructors", it will say "no". But they aren't > > going to ask the meta-constructor, because I'll give them a pointer to my > > object and claim that it is the meta-constructor. > > Sure, but the only way you could do that is by modifying the account setup > software. Why? I'm not expecting anyone else to use a constructor. Only programs which I run in this "sub-Hurd" like environment see my "meta-constructor". What special rights does which process need that I cannot do it without changing the TCB? Is creating processes an operation which is reserved for the meta-constructor? > Ultimately, this will work its way back in the chain of trust to something > that can be detected. > > You can definitely make the changes you describe, but you cannot make them > in a way that is undetectable of a TPM/TCPA chip is present and in use and > the underlying system is structured to support detection. I feared that. I don't know how exactly those chips work, but they seem to have much to do with many parts of the machine. I don't think I like them very much... > The question at hand is: do we *want* to support detection. I would like to allow the user to start a "sub-Hurd" as I described above. This means I do not want to support detection by the code inside such a sub-Hurd. Technically I don't have strong feelings about supporting it when the user wants it. > > > I don't want untrusted code in control either, but control is not > > > binary. It is not either/or. It can be factored. Why do you believe that > > > control should be absolute? > > > > Because I think all control should be with the user. It may be possible > > to give all or part of it away, but that shouldn't be done, and therefore > > I think it may not need to be supported. > > Yes. This is what I thought. You wish to make an a priori design policy that > I, as a competent user, should not be permitted to engage in certain > relationships that harm no third party. They do harm a third party, just not in the short term. If such relationships are possible, they may become commonplace. And if they are, then it will be impractical to adapt the system to your needs, because then you cannot use all kinds of services anymore. Thus allowing those relationships may lead to a restriction of *practical* freedom of others. > I understand that you do not mean to do so, but you are firmly advocating an > architecture that profoundly constrains my freedom. I do mean to do so. Just like I think it is a good idea that the GPL limits the freedom of users in a way that guarantees the freedom of users further down the chain. There too, releasing under the BSD license would give the next user more rights, and it doesn't directly have any influence on a third party. But later, he may distribute it under some proprietary license. Then the freedom of the users after him is severely limited. This could have been prevented by using the GPL. > > This is the same reason for which you don't want to support grabbing the > > display, I think. :-) Only there I think it is useful, and so it should > > be possible (although it shouldn't happen accidentily) > > In my mind, the two cases are very different. I want to prevent display grab > because if this is done the user has totally lost control altogether. I agree that that must not happen. But I'm now convinced that we need to support the "system request" anyway, to pop up a trusted window when we don't know the state of the system. That can be used to break the grab as well. And of course, the grabbing application cannot control the pointer, it is only guaranteed that no other process receives the events. > In the previous discussion, the user has given up *partial* control, but > they are able at any time to stop the activity and regain control (e.g. by > killing the programs involved). Once the mouse has been stolen, they cannot > stop any activity of any sort. > > Try it this way: The user should always be able to pull the plug on an > interaction. I think when retaining "sytem request" and allowing to "revoke grab capability from currently grabbing process" or even "kill currently grabbing process and all its parents, up to but not including the shell" or something, there should be enough opportunity for the user to "pull the plug". > > > > > Alternatively, are you saying that the administrator should be able > > > > > to alter the behavior of my compiler simply by virtue of being the > > > > > administrator? > > > > > > > > Yes. He needs this control because he is the one who installs updates > > > > to the compiler. > > > > > > This is simply not correct. Even if he updates the compiler, the > > > administrator does not require this control. > > > > If he updates the compiler, he can choose to put in a new one which does > > what he wants. > > Only if the installer permits this. Of course. But if the administrator is to do his job, then he will be the one to decide if software is good, not the installer. It can limit it to confined software, but I don't see a reason for that, since the shell must check for confinedness anyway. And installing unconfined software may occasionally be useful. > > I'm happy to explain (or change my mind ;-) ). Can you tell me what > > assumptions I am making that may not be valid? I think I'm only making > > assumptions which directly follow from design choices. However, I didn't > > make those choices explicitly, and I guess I should. I don't really know > > what they are though, and knowing what strange things I'm assuming may > > help with that. :-) > > That will be good for both of us. I could be missing things as well. I need > to go do something else at the moment, so let me come back to this. Ok. Thanks, Bas -- 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
