Groups | Search | Server Info | Login | Register

Groups > gnu.hurd.help > #362

Re: Combining Hurd and Qubes OS for security reasons? Possible?

Show key headers only | View raw

Hi,

On Fri, Dec 18, 2015 at 07:26:53PM +0100, David Renz wrote:

> I'm new to this mailing list, but already have many years of Linux
> experience behind me and have read a lot about GNU Hurd, which gave me
> the impression that it offers a quite high level of security due to
> its limited attack surface.

Well, it isn't specifically geared towards that -- but in theory (i.e.
minus bugs), it should be somewhat safer than monolithic systems
nevertheless.

> E. g., there are (not only on theoretical presentations, but also in
> the real world) so-called 'ACPI'- or 'BIOS-Rootkits', which are
> capable of manipulating Windows as well as Linux systems. Since Hurd
> follows a different approach of accessing hardware components, I often
> wondered whether this could make it resistent against those kind of
> rootkits, but I can't really estimate this considering several facts
> about those. (Maybe others would be able to guess whether a Hurd-based
> system could be manipulated by any kind of malicious code hiding in
> (flashable) firmware components [this problem also affects PCI
> devices' firmware and other components...].)

I don't think it makes a difference. Running the ACPI interpreter in a
separate address space would isolate faults caused by bugs in the
interpreter -- however, that's not how these ACPI rootkits work. Rather,
they just plainly tell the interpreter to execute harmful operations. I
don't believe there is any way to protect against that: the interpreter
*has* to execute dangerous operations to actually control the hardware.
While the most obvious invalid operations could be catched, there is no
way it could catch *all* harmful operations. (Not even theoretically,
unless it fully understands the hardware -- in which case ACPI would be
pointless anyways...)

OTOH, I'm not sure protecting about this specific kind of exploits would
even make a difference. The BIOS has full control over the hardware
anyways -- using this specific attack just makes it somewhat easier to
hook into the OS functionality at best AIUI.

> Wouldn't it potentially increase one's security by many times, if one
> would be able to let (e. g.) Debian Hurd as a template VM on top of a
> Qubes OS system? I'm sure it would be really difficult to put this
> idea into practice, but basically this should be possible to do, or am
> I missing a fact which make this be impossible?

Well, you could certainly do that -- though I'm not sure there is
actually much point to that... The Hurd architecture naturally lends
itself to implementing container solutions. (Hypothetically at least --
as for things actually implemented, the subhurd mechanism is all we
actually have there...)

Now on monolithic systems, containers are a major step backwards in
terms of security compared to full virtualisation, because the
monolithic kernel is responsible for all security enforcement again,
with no fault isolation whatsoever. (While with full virtualisation, the
hypervisor and guest OS can provide additional security layers.) But on
the Hurd it's different: the confinement mechanisms for containers can
be implemented in isolated processes -- thus theoretically offering a
similar level of security as full virtualisation, while still having
overhead not significantly larger than other container solutions...

This is an area I have been considering very interesting to explore
further in the Hurd for many years (see
http://tri-ceps.blogspot.de/2007/10/advanced-lightweight-virtualization.html
) -- long before the recent Docker-induced container boom...

-antrik-

Back to gnu.hurd.help | Previous | Next | Find similar

Thread

Re: Combining Hurd and Qubes OS for security reasons? Possible? Olaf Buddenhagen <olafbuddenhagen@gmx.net> - 2015-12-24 03:33 +0100

csiph-web