At Tue, 11 Oct 2005 21:10:58 +0200, Alfred M Szmidt wrote: > > Also, if you think it is just an exploit in the implementation, and > not a design flaw, you will surely have a way in mind to fix the > implementation. Please share that with us. I am very interested to > hear about it. > > Well, since chroot is inherently unsecure on all platforms (chroot was > never designed to be secure!), it would be simpler to deprecte it and > come up with another scheme. What the exact scheme is, I do not know > yet, but something like sub-hurds.
It is not true that "chroot is insecure on all platforms". This is simply a false statement: chroot is "secure" on many platforms today, and this does not only include specifically hardened platforms. By secure I mean that it effectively restricts filesystem access. If you are looking for an alternative, one that works and is actually used around the world, have a look at BSD jails. They provide a more thorough encapsulation than chroot. > Then you have reintroduced the single global namespace that Unix > has, and you have just removed security, and not added to it: All > files are accessible to all programs. > > I fail to see how this has been reintroducded, sub-hurds don't have > the same global namespace. You keep beating on subhurds, but you fail to show how they are relevant in this discussion at all. A subhurd is as relevant here as a second machine, with its own copy of the operating system. Right, a second machine is encapsulated, it can not access the files on the first machine. What's your point? Let me take your argument to the extreme. The extreme would be: "Ok, the Hurd is insecure, but it wasn't meant to be secure. So, just run the program on a different Hurd system." There are two flaws in this line of thinking: First, the second Hurd system is not going to be any more secure than the first one. That can be acceptable, because its insecurities are contained. More seriously, there is no way of sharing anything between the two separate Hurd systems. This achieves your goal of separation, but it over-reaches it at the same time. The whole purpose of having this discussion is to find out how to enable selective, narrow sharing. In your system so far, I have the choice to share everything, or to not share at all. This is overly restrictive and does not lead to usable systems. > So, getting rid of chroot is exactly the wrong way to go about it. > > I disagree. > > There is no reasonable way to share resources between the Hurd and > a subhurd (actually, there is a way: > > Then such a means should be implemented, some kind of a proxy > translator where you specify what resources you can use from within > the sub-hurd (think firewall). Right. This is exactly the problem I was talking about in my original mail. How can you specify what resources a certain confined task is allowed to use, and how do you enforce such restrictions? You have now arrived at a point where you have to face the original questions I was implicitely asking. It doesn't really matter if you put them into the context of passive translators, user IDs, or subhurds. It's always the same game. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
