begin Adam Heath quotation: > I agree with Anthony here(shock, that). The very idea that hurd > developers think that any software written on or for(or running on > thru emulation) hurd is perfect, is completely asinine. To be fair, I believe only Jeroen Dekkers has said or implied that in this thread. > When hurd is released, software will be run on it. Software that was > released with Debian, *AND* software from other sources. You may think > software released with hurd will be secure, but what about after the > fact? How often have you installed a testing or unstable package on a > stable box? Either thru a recompile, or by upgrading certain packages? The claim (Jeroen's) seems to be that the design of the Hurd is such that it doesn't matter if some program is insecure; it won't have access to anything sensitive, certainly not write access. So the spectre of some insecure third-party package allowing a serious exploit is, if I understand Jeroen's messages, not realistic. However, I disagree, and I frankly don't think one needs to understand the Hurd's advanced and brilliant design to see the holes in his reasoning. It doesn't matter, because the same objections would apply to ANY security system, no matter what it's based on; they are more fundamental than any particular system's design or implementation. Two obvious objections that spring to mind offhand (there are many more, I'm sure, if one stops to think about it) are: - No matter how well the HURD is designed, it may have bugs in its own code, at any level (kernel or userspace), that somehow end up allowing access that should not have been allowed. Jeroen's claim that this is not possible is based not only on the HURD's allegedly fantastic design, but also, it seems to me, on the unjustifiable (nearly inconceivable) assumption that the HURD and the microkernel under it have no bugs. I simply can't accept that. - Even if an exploited program can only allow access to its own data, that may be quite bad, if the data it has access to includes sensitive material or information that can help the attacker break into other programs where the really important data is kept (which ordinarily would be firewalled, but according to Jeroen, firewalls are useless, so we'll assume they are reachable). Craig
Attachment:
pgpp2n6QL6Vzb.pgp
Description: PGP signature