Combining Hurd and Qubes OS for security reasons? Possible?

[David Renz]

Hello everyone,

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.

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

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?

Any feedback would be highly appreciated, thanks in advance!

David

[Samuel Thibault]

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.

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

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

Samuel

[David Renz]

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

[Samuel Thibault]

David Renz, on Sun 20 Dec 2015 22:40:03 +0100, wrote:
> 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.

I don't know. See the code in ./i386/i386at/acpihalt.c. That looks like
a small interpreter. I don't know what it's able to do.

> 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?

In the Mach case, yes, because we'd then not use ACPI at all. I guess
it's the same with Linux.

> > > 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 can only guess so, I don't know what Qubes provides beyond Xen.

Samuel

[Richard Braun]

On Sat, Dec 19, 2015 at 11:28:43PM +0100, Samuel Thibault wrote:
> 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.

The only part of ACPI really needed for SMP is the table that replaces
the MP Spec. See X15 [1] for an example. I highly doubt it would lead to
code execution. Those blobs mostly come from non architectural devices.

--
Richard Braun

[1] http://git.sceen.net/rbraun/x15.git/blob/HEAD:/arch/x86/machine/acpimp.c

[David Renz]

The ACPI system is a subsystem of the BIOS, which itself is patchable firmware. I would never exclude the chance that ACPI code could get executed, no matter which OS one is using actually - There are also PCI devices containing (patchable) firmware etc.

Unless one would be using an open-hardware/openBIOS based system, I don't think that security could be achieved on modern (x64) hardware with all its patchable firmware components. You can only 'limit the attack surface' otherwise - That approach might work or not. I'm certainly not a fan of Shuttleworth, but in my opinion he summarizes this whole issue quite well:
https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Security_risks

As far as I know, the Raspberry PI does not contain any hardware component, whose firmware could be 'patched' without having physical access to it, so maybe that would be a starting point (or any other system, where this is applicable).

Then you would still have to deal with software based exploits, but at least one could fix those once having detected them. But if your system contains hardware with 'patched' firmware, this would be far more difficult if not even impossible.

[Richard Braun]

On Tue, Dec 22, 2015 at 06:05:07PM +0100, David Renz wrote:
> The ACPI system is a subsystem of the BIOS, which itself is patchable
> firmware. I would never exclude the chance that ACPI code could get
> executed, no matter which OS one is using actually - There are also PCI
> devices containing (patchable) firmware etc.
>
> Unless one would be using an open-hardware/openBIOS based system, I don't
> think that security could be achieved on modern (x64) hardware with all its
> patchable firmware components. You can only 'limit the attack surface'
> otherwise - That approach might work or not. I'm certainly not a fan of
> Shuttleworth, but in my opinion he summarizes this whole issue quite well:
> https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Security_risks
>
> As far as I know, the Raspberry PI does not contain any hardware component,
> whose firmware could be 'patched' without having physical access to it, so
> maybe that would be a starting point (or any other system, where this is
> applicable).
>
> Then you would still have to deal with software based exploits, but at
> least one could fix those once having detected them. But if your system
> contains hardware with 'patched' firmware, this would be far more difficult
> if not even impossible.

Not being able to easily update firmwares isn't acceptable nowadays.
Having code running on the hardware is actually perfectly acceptable,
as long as you are aware and accept that these are small systems of
their own. You just can't prevent firmwares from doing all sorts of
things unless you also accept to severly restrict what future updates
can do.

The real problem is actually not the firmware itself. The problem is
that the firmware often has access to more than it needs, on the basis
that, as a hardware component, it is considered part of the trusted
computing base. This means it can access all physical memory. The
real solution for this problem, which mixes very well with a
multi-server design such as the Hurd, is to use IOMMUs. In the Hurd
world, an I/O server would provide access to memory ranges through
capabilities and mappings, programming the IOMMU accordingly, in
a way very similar to the classic MMU with per-process mappings,
so that devices are restricted in what they can access.

In the case of ACPI though, I'm not sure whether IOMMUs actually
enforce access verification in system management mode, but if it
does, a properly implemented multi-server system with IOMMU
hardware should be able to provide a high level of security
despite those shortcomings.

--
Richard Braun

[Arne Babenhauserheide]

Am Dienstag, 22. Dezember 2015, 18:34:16 schrieb Richard Braun:
> On Tue, Dec 22, 2015 at 06:05:07PM +0100, David Renz wrote:
> > Unless one would be using an open-hardware/openBIOS based system, I don't

> …

> Not being able to easily update firmwares isn't acceptable nowadays.
> Having code running on the hardware is actually perfectly acceptable,
> as long as you are aware and accept that these are small systems of
> their own.

Taking out all the details in-between it sounds like you pretty much
agree (at least on the big picture). If the code on the hardware is a
small system of its own, then it should be free software, which means
it would run openBIOS.

> In the case of ACPI though, I'm not sure whether IOMMUs actually
> enforce access verification in system management mode, but if it
> does, a properly implemented multi-server system with IOMMU
> hardware should be able to provide a high level of security
> despite those shortcomings.

So you mean that with the Hurd it might be possible to get a trusted
system despite having some unfree components?

Best wishes,
Arne

[David Renz]

I didn't want to write this, but that's how it is (concluding that this is not possible with some unfree firmware components).

I see two ways out of that:
1) One could easily use two separate systems for two different purposes: Use one system, which doesn't provide any networking capability, for productivity etc. (Or use a system which is online, but keep in mind that you shouldn't use it for online communication others shouldn't be able to intercept.)
2) Use a Raspberry Pi running OpenBSD (just as an example, there would be numerous other solutions) for encrypting/decrypting and receiving/sending communication.

The other approach would be using a system running openBIOS, so you could combine both things. I can't evaluate how realistic this would be, since you would also have to think of patchable firmware in PCI etc. components. Running openBIOS should be a basic premise for a 'secure' x86 system however.
You can under no circumstances get a secure system running on one or multiple "system(s) of its/their own", because - as you have said it very precisely - you have no control over this.

[David Renz]

Just one of many interesting articles addressing this issue:
http://www.toucan-system.com/research/blackhat2012_brossard_hardware_backdooring.pdf

Best wishes and merry Christmas to everyone

[Richard Braun]

On Wed, Dec 23, 2015 at 09:20:37AM +0100, Arne Babenhauserheide wrote:
> Taking out all the details in-between it sounds like you pretty much
> agree (at least on the big picture). If the code on the hardware is a
> small system of its own, then it should be free software, which means
> it would run openBIOS.

No, I mean people must be aware they can't trust it if it's not open
source. But the same way admins don't trust user processes and use the
kernel to enforce boundaries, your hardware can also do it.

> > In the case of ACPI though, I'm not sure whether IOMMUs actually
> > enforce access verification in system management mode, but if it
> > does, a properly implemented multi-server system with IOMMU
> > hardware should be able to provide a high level of security
> > despite those shortcomings.
>
> So you mean that with the Hurd it might be possible to get a trusted
> system despite having some unfree components?

I only mean that the Hurd is more suitable to protect the system from
individual drivers than a monolithic system.

--
Richard Braun

[Richard Braun]

On Wed, Dec 23, 2015 at 11:56:23AM +0100, David Renz wrote:
> You can under no circumstances get a secure system running on one or
> multiple "system(s) of its/their own", because - as you have said it very
> precisely - you have no control over this.

That's not what I said. First, you don't run a secure system "on one or
multiple systems of their own". You run one system among multiple ones.
Then, that system must have control over memory access because that's
where the data is and that's what you want to protect. Finally, you
need hardware that can actually restrict memory access from devices that
are external from the point of view of that main system and physical
memory.

After reviewing SMM a bit more, it seems to be an x86 processor operating
mode, giving access to normally inaccessible resources, hidden from the
operating system, which means firmwares using that mode actually run on
the main processor, and are subject to neither IOMMU nor MMU restrictions.

If I'm right, it seems you just can't protect an x86 system from firmware
interference.

--
Richard Braun

[David Renz]

On Wed, Dec 23, 2015 at 4:41 PM, Richard Braun <rbr...@sceen.net> wrote:

On Wed, Dec 23, 2015 at 11:56:23AM +0100, David Renz wrote:
> You can under no circumstances get a secure system running on one or
> multiple "system(s) of its/their own", because - as you have said it very
> precisely - you have no control over this.

That's not what I said. First, you don't run a secure system "on one or
multiple systems of their own". You run one system among multiple ones.

But the important thing about this is: Those other systems have access to your 'main system', as you also wrote in your last line - I don't believe that a protection would be possible, too.

 

Then, that system must have control over memory access because that's
where the data is and that's what you want to protect. Finally, you
need hardware that can actually restrict memory access from devices that
are external from the point of view of that main system and physical
memory.

After reviewing SMM a bit more, it seems to be an x86 processor operating
mode, giving access to normally inaccessible resources, hidden from the
operating system, which means firmwares using that mode actually run on
the main processor, and are subject to neither IOMMU nor MMU restrictions.

If I'm right, it seems you just can't protect an x86 system from firmware
interference. 

That's why I often asked myself why not trying approaches based on other hardware architectures - RaspberryPi might be worthy to look at for that purpose.
 

--
Richard Braun

[Richard Braun]

On Wed, Dec 23, 2015 at 05:25:08PM +0100, David Renz wrote:
> On Wed, Dec 23, 2015 at 4:41 PM, Richard Braun <rbr...@sceen.net> wrote:
>
> > On Wed, Dec 23, 2015 at 11:56:23AM +0100, David Renz wrote:
> > > You can under no circumstances get a secure system running on one or
> > > multiple "system(s) of its/their own", because - as you have said it very
> > > precisely - you have no control over this.
> >
> > That's not what I said. First, you don't run a secure system "on one or
> > multiple systems of their own". You run one system among multiple ones.
> >
>
> But the important thing about this is: Those other systems have access to
> your 'main system', as you also wrote in your last line - I don't believe
> that a protection would be possible, too.

Outside SMM, with an IOMMU, they can be restricted.

--
Richard Braun

[Olaf Buddenhagen]

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-