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

Am 19.12.2015 23:28 schrieb "Samuel Thibault" <[email protected]>:
>
> Hello,
>
> David Renz, on Fri 18 Dec 2015 19:26:53 +0100, wrote:
> > E. g., there are  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,
>
> It will most probably be resistent to windows- and linux-oriented
> rootkits, since the implementation is different.  If there are flaws in
> the ACPI implementation of GNU Mach, there are probably ways to rootkit
> it.  GNU Mach however currently uses ACPI only for shutting the system
> down, so the exposure is low.  We'd however need it to eventually work
> with multicore processors.

What interests me a lot about GNU Hurd is some people's claim that it would
have a "limited attack surface" due to its specific design, especially
referring to the way it accesses hardware and the general kernel design -
Which might (!) lead to the conclusion that it's more secure than Linux e.
g. However, nothing is more dangerous than feeling secure without actually
being secure, as all of you would probably agree.

You already 'admitted' (single quotation marks since that's certainly the
wrong word - I admit my poor English without using single quotation marks)
that in some way or another also Hurd would make use of ACPI code.
Now there are two critical questions to me:
1) I have seen ACPI code in 'real life' which is able to modify Windows,
Linux and BSD systems on the same computer (probably code stored in the
DSDT table). So even if Hurd would use ACPI only e. g. for shutting down
the computer: Could the according function call used for shutting down the
computer lead to other ACPI code being executed? I would guess that this
might be possible.

2) If booting Hurd or Linux with the "acpi=off" boot parameter, would this
rule out the possibility that (malicious) ACPI code might get executed?
The OS still interacts with the BIOS, which is also just patachable
firmware and the ACPI code is in fact part of this, so could such a boot
parameter really prevent the execution of ACPI code for certain?

> > 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?
>
> Well, that'll replace the GNU Mach ACPI implementation with the Xen
> implementation, i.e. trading one security surface by another. Since the
> Xen one is well-tested, that can be a good trade :)

Wouldn't a Qubes OS Hurd template be very much like running on a (perhaps
more secure) VM? I thought of it in the way of (recursively) 'limiting the
attack surface', like the approach they do by using a Whonix template.

There was an issue regarding the security XEN might offer which had been
discussed in one of the Qubes OS security bulletins, so you may find some
information there. I think this mailing list is not the right place to
discuss about XEN.

>
> > 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?
>
> GNU Mach is already ported to Xen, so it should be fine with Qubes.

(s. above: Maybe it would be worthy to give it a try then. It's not that
easy though to 'just' create a Qubes OS template based on any kind of OS,
even if it has already been ported to XEN.)

>
> Samuel