[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hurd does NOT need /hurd

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).


Attachment: pgpp2n6QL6Vzb.pgp
Description: PGP signature

Reply to: