On Tue, May 16, 2006 at 01:14:00PM -0400, Jonathan S. Shapiro wrote: > My apologies. The last few days have been stressful for reasons that > have absolutely nothing to do with Hurd or the current discussion.
Although I am often curious what your reply will be, I would advise you in such situations to delay the reply until you have some more rest, or else only write a very short note that your reply will be delayed. > > > EROS does this because 40 years of experience says that the default has > > > to be opaque or security fails. > > > > That sounds reasonable. It also sounds incorrect. :-) > > Then I don't think you understand security yet. :-) > > Seriously: it is a long-standing principle of secure and robust design > that things should default closed and programmers should have to make > conscious, intentional decisions to open them; never the other way > around. Ah, this was higher level than I expected. I thought this was specifically about the space bank. I agree with this principle. However, I don't think the "transparent space bank" approach is in conflict with it. Any important is started directly by the user. That means that only the session (TCB) is a parent of it. The session allows access to programs only to the user's shell (TCB). So the "danger" in that case is that if the session or shell is compromised, the attacker can debug the program. You know what? If the TCB is compromised, you have bigger problems. So I don't think it's relevant in that case. Analogously, when a "real" program (started from the session) starts a subprogram (a plugin, for example), and the parent gets compromised, the subprogram is lost anyway. If the subprogram can reasonably run without the parent, then it is probably a good idea to not make it a subprogram, but let the parent ask the session to spawn it, so it gets its own powerbox. Then it also is protected from the "parent", because the parent isn't actually a parent, but a sibling. In short: a subprogram spawned from a program is under complete control of the program. It has nothing to hide. It is _defined_ by the parent, so the parent simply defines that it has nothing to hide. (This is very different from the government/citizen problem of privacy, because the government doesn't define the citizen.) If the parent thinks it's a good idea that the child can hide things, then it arranges for this by asking its parent (usually the session) to create a sibling. There are situations where programs want to hide even from the user's shell. This can of course be arranged in the session, by giving out sub-space banks to which the shell is not allowed. This can for example be used to store encryption keys. Yes, the session (and the primary space bank, and the kernel) can still access that memory. But we trust that they don't. That's why it's called TCB. If we have a bug in the TCB, and in particular in one of those parts, which allows an attacker to take control of them, then we're completely lost. With an opaque space bank, this part gets limited to only the kernel, I think. However, the price is too high. Consider the following use case: Jack is happily running Hurd on his computer. I gave him a server S for doing foo, and he has been using it for 3 years already. Now his computer is doing strange things. He doesn't know a lot about computers, so he asks me. I find out that S is doing weird things, and I want to debug it. I specifically don't want to restart it in "debug mode", because I've tested it many times and never found any problems. It might have to do with the fact that it has been running for 3 years. So if I restart it, I might need to wait 3 years. That's not acceptable. Luckily the Hurd allows the user access to his resources, so I can directly debug S and (hopefully) find the problem. Note that in this example, Jack is not a programmer. So "programmers should set the default to debuggable" isn't a solution. > > Ok, this is a technical thing. I'm assuming that the space bank can > > provide me a page of memory which I can use. If it's hard, I'll use a > > library for it. No problem. > > It can. The difficulty is that the space bank has no idea how you glue > together the pieces that it hands you. The situation is similar to > having a disk driver that will give you back any block that you want. > You still need to know how the file system is structured to make this > useful. > > Except that the process relationships are more complicated than the > relationships of data structures in the file system. If the constructor can do it, then a library can as well. I don't see how complexity can be an argument here. > > You are assuming that there is a constructor, and you add something to it to > > make it "simpler". I am removing the constructor (moving part of its > > functionality, creating a new process, into a library) and claim that that > > really makes things simpler. It removes a step of indirection. Instead of > > asking a server (the constructor) to create a process, I can just do it > > myself. > > This is a VERY bad idea, for reasons that have nothing to do with > encapsulation or transparency. > ... some stuff why shared libraries are bad ... > > This has nothing to do with the open/closed/transparent issue. It's a > simple matter of fault isolation. This is why I have stated my opinion > that Hurd should use the Constructor pattern for process creation even > if it does not impose the encapsulation and opaqueness properties. While I think the problems you described may be solvable, I wasn't actually thinking about shared libraries. I was thinking about static libraries. The point is that if something requires complex code, that is no reason to move it into a separate process. It's a reason to prepare the code in advance and use it when needed. One way of "preparing" is to put it in a process of its own. A library (which can be static) is another way, and it's less complex IMO. > > > Opaqueness is like virginity. Once you give it up, you can never get it > > > back. In consequence, if *any* process *ever* requires opaqueness, the > > > default must be to make storage opaque. > > > > Nonsense. If a process requires opaqueness, there must be a way to > > allocate opaque storage. There's no reason at all that it must be the > > default. > > The problem with your approach is that it only takes one omission by a > single programmer to expose a whole lot of stuff. Not at all. Consider the constructor-approach: every spawned process will be a sibling of every other one. It's a flat structure, really. Therefore, using a transparent space bank in that case doesn't change anything, because the parents (that's the constructors) aren't going to look at the memory anyway. The approach I was thinking of is quite close to this. Except that the session is the parent of most processes of a user, not the constructor. And so the user _can_ look at all his programs. And that's a very good thing. There is a very limited class of programs which is not started by the session, but by programs themselves. These are all helpers, which do something for their parent. For them, it is no problem if the parent can look at them. If the parent gets compromised, they become useless (because the type of help they provide no longer fits with what the parent wants). If they themselves get compromised, there is no problem for the parent: the transparency doesn't work the other way. > If opaqueness is the default, and you leave out the "make it visible" > option, your program tends to break very quickly and you notice it. Not at all. In my use case above, it took 3 years (which obviously was an arbitrary "long time"). > If opaqueness is an option and you leave it out, it is very easy to ship the > program to the field without ever noticing. There is a big difference between "spawning a program" and "spawning a helper". Both have different defaults. For a helper, transparency is the default. For a program, opaqueness (to the instantiator) is. If you spawn a program, but accidentily make it a helper, you will very soon find out that this helper requires a power box. At which point you will notice your mistake. Of course, you can also give it a power box, but in that case you probably know what you're doing, and it's good as well. (You're probably running in a sub-hurd, and your parent is the sub-session.) > > > This is fundamental. There really *are* programs that need to manage > > > sensitive state, and you really *don't* want those programs (in most > > > cases) to have to run off of system-supplied storage. > > > > Actually, I think in most cases we very much do want this. Maybe even in > > all cases (but we're still discussing that). > > In order for such a program to be correct, it must be designed in such a > way that all request messages to this services have payload sizes that > can be statically sized at IPC compile time. Not at all. We can let the user provide any storage we need, except for parts which must not be disclosed to them. Obviously a buffer for an IPC transfer may be disclosed to the user. > > > The system design that Marcus proposes relies on a process hierarchy > > > with trusted system processes close to the top. A problem with this > > > design, which will become apparent to developers after 2-3 years of > > > coding, > > > > If you see it coming already, then it should be easy for you to find an > > actual use-case where this problem shows up. Please share this with us. > > Bas: Marcus has made it clear that he wishes me to diminish my > participation, and I have a product to deliver. I simply do not have time to > devote to this activity when it is unlikely that my input will produce any > value. I know, and I'm not happy at all with it. But you sounded like you already had several examples ready. If that is the case, I would like you to tell us. If it costs more time, then I can understand that you don't want to spend that on it. But as I said, I'm not happy with that. > > > is that this design only works in a transparent storage design IF those > > > servers supply the storage for all of the operations that they perform > > > (i.e. they never rely on user-supplied storage). > > > > They shouldn't rely on user-supplied storage for things that they don't > > want to share with the user. They can rely on user-supplied storage for > > all other things, which is a lot. Actually, the non-sharable part would > > usually be constant size, I think, so in that case there is no problem. > > It turns out to be surprisingly easy to have an IPC that has a > dynamically sized element. Anything that passes a string as an argument > is an example... But those don't fall in the category "that they don't want to share with the user". > > > The problem with this is that there is a "free rider" problem that leads > > > directly to denial of resource. > > > > It would if the size is not O(0). Please give an example of a case where > > it isn't. > > POSIX open(2). You mean the pathname argument? I thought you wanted that to have a real PATH_MAX. :-) Anyway, it's not something that the user can't know. > POSIX read(2). This too, is not something that the user may not see. Except of course if the server needs to read on request of the user from a protected file. But in that case the server defines the buffer size, so it is O(0). > > > I am very very concerned about the extremist ideology of transparency > > > here. This goes ORDERS OF MAGNITUDE beyond what is required by GPL or > > > FSF. > > > > Does it? The only new part is that --x permission cannot be given. That > > is, x implies r (and r implies x). I don't think I've ever seen a > > situation where users were not given read-permission to a binary that they > > could execute, that was actually useful. The only reason I know for its > > use is to make it harder for crackers to find bugs in it. That is > > security through obscurity. It doesn't work. > > This is such complete nonsense that I don't quite know where to begin to > explain how wrong it is. I will try to respond to this tomorrow, when I > am not up against a critical deadline. That's the sort of "note" I meant at the start of this e-mail. Good boy. ;-) > > That's not what Marcus' proposal says either. The only "new" thing > > (compared to EROS) is that it says "if you want me to run your code, you > > need to give it to me". > > This also goes FAR beyond GPL. The GPL is about other things, not about what users within one system do. The GPL says things like "If you give me a CD with your program, you must provide the source code". This is about users within one system, running each other's programs. As I said, if I want you to run my program, I have to give you a CD with the program on it in normal life. In this case, it is technically possible that I don't. This is not something the GPL talks about. > > But for us, "I want to run your code, but you don't need to give it to > > me" is something new. And we don't see the usefulness of it as > > automatically as you do. > > Obviously it is not new to the GPL community, because this question > precisely was a long part of the discussions of GPL3, and the outcome > was MUCH less strict than the outcome that you are contemplating. I didn't follow these discussions very closely. But this question is about "who pays". I can't imagine that the GPL discussion was about this, because it is simply irrelevant on current systems (that is, GNU/Linux). All you want is totally possible with a transparent space bank. The only thing is that the one who wants to keep his program secret has to pay for the storage. Ok, and encapsulation isn't guaranteed to the instantiator. > > The storage is transparent to the user himself, not to the rest of the > > world. It is based on the assumption that only users have rights, and > > programs don't. > > Actually, I think that this statement is a very good summary of the > essential assumption. I think that this essential assumption is going to > be a problem, and I will try to explain why tomorrow or the next day. I look forward to it. 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
