help-hurd
[Top][All Lists]
Advanced

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

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


From: David Renz
Subject: Re: Combining Hurd and Qubes OS for security reasons? Possible?
Date: Sun, 20 Dec 2015 22:40:03 +0100

Am 19.12.2015 23:28 schrieb "Samuel Thibault" <samuel.thibault@gnu.org>:
>
> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]