On Sun, 2006-04-30 at 23:17 +0200, Marcus Brinkmann wrote: > Propose a use case for non-trivial confinement. Could you please define the term clearly, so that the discussion can be productive? I do not wish to mis-characterize what you are actually proposing. shap
At Sun, 30 Apr 2006 18:22:05 -0400, "Jonathan S. Shapiro" <shap <at> eros-os.org> wrote: > On Sun, 2006-04-30 at 22:20 +0200, Marcus Brinkmann wrote: > > > > Neither am I. I was trying to make a legitimate point. Absolute > > > positions in moral matters have the problem that they fail in real-world > > > cases. Killing the injured horse is an example of a case where this > > > occurs. When one person takes a dogmatic position, the opposing person > > > only has to find *one* legitimate counterexample in order to demonstrate > > > that the dogma is harmful. > > > > You are insinuating that I have a dogmatic position. This is not the > > case, as is demonstrable by looking at what I actually said. It is > > also very easy to find out by asking me if I have a dogmatic position > > (the answer is no). I said, explicitely and with no possibility of > > misunderstanding, that a weapon may be a useful tool, under > > extraordinary circumstances. This is not a dogmatic position, but > > easily identified as a pragmatic position. > > But this was not the position that I am referring to. I am referring to > the position on DRM. My opposition to DRM is not a dogma, it is derived from my personal experience and intellectual analysis of the history of freedom of thought and culture. This analysis is based on fact, not opinion. > > > I am not convinced that my example, which is a real-world example, was > > > either narrow or stupid. If *you* think it is stupid, try looking at it > > > from the horse's point of view. > >(Continue reading)
At Sun, 30 Apr 2006 18:24:19 -0400, "Jonathan S. Shapiro" <shap <at> eros-os.org> wrote: > > On Sun, 2006-04-30 at 22:29 +0200, Marcus Brinkmann wrote: > > At Sun, 30 Apr 2006 20:29:28 +0200, > > Pierre THIERRY <nowhere.man <at> levallois.eu.org> wrote: > > > > 2) If someone implements [confinement] will it be integrated in the Hurd, even > > > if disabled by default? > > > > This doesn't even make sense if the issue were not contentious. > > I believe that Pierre is asking "If someone implements it, will the Hurd > designers reject integrating it because of politics?" (Please note: > Marcus himself described this as a decision motivated by the politics of > ownership). > > I think this is a perfectly legitimate question. What is your response? You said in another mail: > I do not believe that > true confinement can be added to the system later in any practical > sense. Architecting it out is, for all practical purposes, banning it. I said, many times now, that I do not know a legitimate use case that is relevant to the GNU Hurd. I have put up a challenge to find one. Assuming that no legitimate use case is found, and that you are right that introducing this feature means a fundamental shift in the(Continue reading)
On Mon, 2006-05-01 at 01:21 +0200, Marcus Brinkmann wrote: > At Sun, 30 Apr 2006 18:22:05 -0400, > "Jonathan S. Shapiro" <shap <at> eros-os.org> wrote: > > Please explain why my comments about architecture and bullshit sophistry > > are a misinterpretation. This would be welcome. I do not believe that > > true confinement can be added to the system later in any practical > > sense. Architecting it out is, for all practical purposes, banning it. > > If that is the case, and it may be, then this reveals the aggressive > nature of the mechanism, and it in fact raises the barrier for > inclusion, because then the legitimation of the whole system would > depend on the legitimation of this single mechanism. I think that this statement is WAY to strong. There are *many* examples of properties and behavior that are difficult to add to systems later if they are not part of the initial architectural considerations. These include things as basic as four digit years (as opposed to two digit years). Surely you would not argue that this should raise the barrier for including four digit years in the feature set? And no, the legitemation of the system does not rest on the initial inclusion of full confinement. Without this feature, the system may be perfectly good at its original objectives. However, it does seem likely that this is one of these properties that is likely to be central to the design, in the sense that it is very hard to retrofit if you decide to exclude it initially and it turns out you were making a mistake.(Continue reading)
On Mon, 2006-05-01 at 01:34 +0200, Marcus Brinkmann wrote: > At Sun, 30 Apr 2006 18:24:19 -0400, > "Jonathan S. Shapiro" <shap <at> eros-os.org> wrote: > > > > On Sun, 2006-04-30 at 22:29 +0200, Marcus Brinkmann wrote: > > > At Sun, 30 Apr 2006 20:29:28 +0200, > > > Pierre THIERRY <nowhere.man <at> levallois.eu.org> wrote: > > > > > > 2) If someone implements [confinement] will it be integrated in the Hurd, even > > > > if disabled by default? > > > > > > This doesn't even make sense if the issue were not contentious. > > > > I believe that Pierre is asking "If someone implements it, will the Hurd > > designers reject integrating it because of politics?" (Please note: > > Marcus himself described this as a decision motivated by the politics of > > ownership). > > > > I think this is a perfectly legitimate question. What is your response? > > You said in another mail: > > > I do not believe that > > true confinement can be added to the system later in any practical > > sense. Architecting it out is, for all practical purposes, banning it. > > I said, many times now, that I do not know a legitimate use case that > is relevant to the GNU Hurd. I have put up a challenge to find one. > > Assuming that no legitimate use case is found, and that you are right(Continue reading)
On Mon, 2006-05-01 at 00:33 +0200, Marcus Brinkmann wrote: > You seemed to have missed a whole thread a couple of weeks ago. This is probably true. I was working toward a deadline, and things were very difficult. Much of the Hurd mail did not get read for two weeks. Sorry. > At Sun, 30 Apr 2006 18:13:07 -0400, > "Jonathan S. Shapiro" <shap <at> eros-os.org> wrote: > > 1. There are overwhelmingly compelling reasons to set policies against > > stupid passwords. > > It is a matter of judgement if such policies need to be administrator > or system enforced. Yes. And the experimental evidence in favor of the need for policy enforcement about choices of password is overwhelming. However, I agree (below) that your proposed mechanism seems like it should work. > > This is why cracklib exists -- one bad password > > endangers an entire system. > > If this is true, then it is a defect in the system. > > The fault is in using passwords. Passwords and humans don't mix well. I agree with both statements. However...(Continue reading)
At Sun, 30 Apr 2006 19:01:25 -0400,
"Jonathan S. Shapiro" <shap <at> eros-os.org> wrote:
>
> On Sun, 2006-04-30 at 23:17 +0200, Marcus Brinkmann wrote:
> > Propose a use case for non-trivial confinement.
>
> Could you please define the term clearly, so that the discussion can be
> productive? I do not wish to mis-characterize what you are actually
> proposing.
Right, that's a good idea. Here is the reformulated challenge that
avoids special terminology alltogether:
Propose a use case for process instantiation where the following
conditions are true:
(1) There is a time just before instantiation and just after
instantiation where the instantiating process does not drop any
capabilities. (This requirement only sets up a definition that is
used in the next requirement.)
(2) In this window of time, there is a point in time where the
instantiated process has at least one capability that the
instantiating process does not have. (_Any_ capability counts).
(3) At no point in time (within or outside the window) can any
behaviour of the instantiated program be observed by any process,
except by the instantiating process and any process directly or
indirectly authorized by it. Assume that covert channels do not
exist.
(Continue reading)
At Sun, 30 Apr 2006 19:56:05 -0400, "Jonathan S. Shapiro" <shap <at> eros-os.org> wrote: > > Assuming that no legitimate use case is found, and that you are right > > that introducing this feature means a fundamental shift in the > > over-all system design, then the answer is clearly that the patch > > would be rejected for technical reasons, independent of any political > > evaluation. > > Yes. I understand this. But it does not answer the question. Pierre is > asking whether your political objections are also decisive independent > of the technical argument. I know better than to answer a speculative question in such a heated debate. You can not expect me to make a decision here on speculative grounds that has to be made by the Hurd project maintainers collectively on factual grounds in the future. Plus, the GNU project also has something to say about that. > You write that you do not know a technical argument that decisively > requires true confinement. In the context of the GNU Hurd, yes. I do know some use cases which I have no interest in supporting (with a varying degree :). > We will certainly work to find one. But if we > *fail* to find one, this is an insufficient reason to reject such a > foundational mechanism. You are omitting the other half of my argument, where I said that I have good reasons to belief that inclusion of this feature is harmful(Continue reading)
I agree with you that behind Trusted Computing and DRM, there are very dangerous ideas like the one that hardware should be the essential enforcer of rules that are otherwise enforced by the society, which creates and interpret them. But there is something very strange, an assumption that you make, in your arguments: why should I own what I use in a computer? In the real world, I use many tools that I have no right to dispose of. If I rent a car, I have limited rights on it's use, idem for my appartment. In the use case of a program that the author doesn't want to disclose to me, I'm just renting it. That's not schizophrenic at all. That's plain normal. > Trusted computing and DRM impose not rules about property of items. > They impose rules about property of digital data. How will TC impose anything? For the moment, we discussed uses of the TC were it gives a (morally objectionable) power to the user (i.e. certification of privacy-related properties of the system). Curiously, Nowhere man -- -- nowhere.man <at> levallois.eu.org OpenPGP 0xD9D50D8A
(Continue reading)
At Sun, 30 Apr 2006 20:20:14 -0400, "Jonathan S. Shapiro" <shap <at> eros-os.org> wrote: > > > 2. I'm not sure how something like 'su fred' would be implemented in > > > this style of system. > > > > You mean as sysadmin without entering a password? No way, unless the > > user grants access to the sysadmin without a password (provided there > > is a mechanism to do so). > > Umm. No. I meant *with* the password. The part I am confused about is > how 'su', which is spawned by me (therefore my child) gains read access > to all of those password files (which is equivalent to read access on > the password database). > > I suspect your answer may be that 'su' is not spawned by me, and that I > have consistently failed to see this. If this is the answer, could you > confirm? Hm, this is an interesting question. First, authentication can either happen by the system, or done by the user. Both solutions are possible, and the decision which one to use has no further impact on the outcome. Authentication is a bounded operation, so there is no hard resource management problem. You also need a way to advertise the user fred of such a login attempt, but of course you need that anyway. However, the critical question is who implements the virtual terminal that fred uses to attach the session to. If the user who does the(Continue reading)
RSS Feed2 | |
|---|---|
3 | |
1 | |
1 | |
1 | |
7 | |
2 | |
1 | |
13 | |
1 | |
1 | |
3 | |
14 | |
1 | |
1 | |
2 | |
35 | |
39 | |
29 | |
161 | |
7 | |
28 | |
6 | |
2 | |
1 | |
2 | |
10 | |
7 | |
16 | |
3 | |
13 | |
2 | |
5 | |
16 | |
2 | |
4 | |
5 | |
6 | |
28 | |
51 | |
19 | |
3 | |
10 | |
1 | |
1 | |
201 | |
66 | |
36 | |
128 | |
8 | |
105 | |
577 | |
416 | |
87 | |
87 | |
40 | |
46 | |
417 | |
904 | |
35 | |
30 | |
43 | |
59 | |
17 | |
53 | |
55 | |
144 | |
138 | |
25 | |
34 | |
162 | |
5 | |
49 | |
16 | |
39 | |
47 | |
35 | |
5 | |
120 | |
34 | |
103 | |
74 | |
28 | |
6 | |
51 | |
148 | |
62 | |
13 | |
8 | |
9 | |
7 | |
73 | |
52 | |
4 | |
48 | |
23 | |
13 | |
33 | |
21 | |
9 |
