Combining Hurd and Qubes OS for security reasons? Possible?

Hello,

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

2015-12-20 21:40:03 UTC

Post by Samuel Thibault
Hello,

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

resistent against those kind of rootkits,

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?

Post by Samuel Thibault
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.)

Post by Samuel Thibault
Samuel

Samuel Thibault

2015-12-20 21:47:02 UTC

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.

Post by David Renz
Wouldn't it potentially increase one's security by many times, if one would

Post by David Renz
able to let (e. g.) Debian Hurd as a template VM on top of a Qubes OS

system?

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

2015-12-22 15:59:35 UTC

Post by Samuel Thibault
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.

--
Richard Braun

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

David Renz

2015-12-22 17:05:07 UTC

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.

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

Richard Braun

2015-12-22 17:34:16 UTC

Post by 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
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

2015-12-23 08:20:37 UTC

Post by David Renz
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.

Post by Richard Braun
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

2015-12-23 10:56:23 UTC

Post by David Renz
Unless one would be using an open-hardware/openBIOS based system, I

don't

Post by Richard Braun
âŠ
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.

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

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

2015-12-23 14:12:55 UTC

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

Post by David Renz

Post by David Renz
Unless one would be using an open-hardware/openBIOS based system, I

don't

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

I didn't want to write this, but that's how it is (concluding that this is
not possible with some unfree firmware components).
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.

Richard Braun

2015-12-23 15:35:37 UTC

Post by Arne Babenhauserheide
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.

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

2015-12-23 15:41:02 UTC

Post by David Renz
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

2015-12-23 16:25:08 UTC

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.

Post by Richard Braun
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.

Post by Richard Braun
--
Richard Braun

Richard Braun

2015-12-23 16:32:25 UTC

Post by David Renz

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

2015-12-24 02:33:01 UTC