RFC: Qubes networking in Beta 1
Joanna Rutkowska
In Qubes Beta 1 we're introducing firewalling and generally a concept of
a ProxyVM, that can also be used as e.g. a VPN gateway for select AppVMs
(e.g. allow work-related domains to connect to the corporate intranet).
This can be now _effectively_ implemented thanks to our new template
sharing scheme implemented by Marek (BTW, Marek can you write some
description of this template sharing scheme in the Wiki?).
There are a few things I would like to discuss regarding this new
networking scheme.
Let's first assume the (much more preferred) scenario when the user has
a VT-d capable laptop and uses a separate NetVM.
In that case we should automatically (by installer's firstboot script I
think) create the _default_ NetVM and FirewallVM:
qvm-create netvm --net --label red
qvm-create firewallvm --proxy --label green
If the user wanted more NetVMs, e.g. wanted to have two separate NetVMs
for each NIC, then the user would need to do that manually from command
line (via qvm-create and qvm-pref). Right now such operation will not be
supported from our gui manager.
Now, whenever the user clicks the firewall edit button in the manager,
we should find the closest FirewallVM connected to the VM whose rules
the user intended to edit (normally, of course, there will be just one
FirewallVM in the chain). So, e.g.:
work -> work-vpn -> firewallvm -> netvm
We should automatically find firewallvm and send the user-created
firewalling rules to that VM via xenstore. We should also warn the user
in case no firewallvm was found in the whole chain! Normally such
scenario would not occur for any AppVM (because we will provide default
netvm and firewallvm and ensure to connect all AppVMs to the default
firewallvm on create), but it might be the case if user manually started
modyfing the configuration (via qvm-pref). Also, some VMs will not have
FirewallVM by definition, e.g. NetVMs, FirewallVMs, or Dom0. In each of
those case, the manager should display an appropriate message and not
open the fw editor. Otherwise, i.e. if we found the FirewallVM we should
display its name in the fw editor somewhere.
BTW, this special treatment of firewallvm (i.e. that we need to look for
it in the chain and send iptables rules to it via xenstroe) suggest that
we should have a special class for it (rather than use the more generic
ProxyVM), of course the child of ProxyVM.
Now, there is the case when the user uses networking in Dom0. This is
much less secure option, but if one has a system without VT-d there is
little (*) security benefit in having a separate NetVM, as it is always
possible for the attacker to break out of it using a DMA attack.
In this case there is no point in separating firewalling code from Dom0
(Dom0 is most trusted anyway). So in this case both NetVM and FirewallVM
functionality should be in Dom0.
Now, this complicates the design a bit, forcing us to maintain
essentially the same code in two places. So, perhaps it would be an
attractive option to always use separate NetVM, even if user has no
VT-d. After all we don't lose anything this way, right?
Or do we? I see two potential problems in using NetVM on non-VT-d systems:
- The malfunctioning driver in NetVM might crash the system if it
incorrectly handles pfn->mfn memory translations, or assume some exotic
access to PCI config space (but this can be addressed via the permissive
flag -- we will argue that it doesn't decrease security even in case of
VT-d system -- a topic for a separate article though)
- There is a known problem with suspend/resume operation, which might
lead to memory fragmentation and might result in the driver in NetVM not
being able to allocate continue DMA buffers, and so failing to enable
the interface after resume.
Both of the above problems seem to apply also to the Dom0 case -- even
in Dom0 the driver must properly handler pfn->mfn translations, and the
memory fragmention problem after resume seems to apply to Dom0 as well?
Still, I remember that when I used to use NetVM on one of my test system
without VT-d a while ago, it tended to crash the system from time to
time (actually hang it). But it might have also be the nouveu driver,
which is know to cause problems even on bare-metal Fedora Linux.
So, the question is what are the others' experience with running NetVM
on non-VT-d systems? Is it stable enough? Should we move to this option
now? Or should we keep manitaning networking in Dom0 as a fallback option?
Of course tray icon support is absolutely needed for moving towards
NetVM-by-default option, but Tomek is apparently already finishing up
this, so it's no longer a stopper.
Please send your comments!
joanna.
(*) One might argue that it still makes the attack much more complex and
requires much more skilled attacker -- one that can not only exploit
DHCP client bug, but also understand the NIC hardware and program it to
do arbitrary DMA.
Marek Marczykowski
> Now, whenever the user clicks the firewall edit button in the manager,
> we should find the closest FirewallVM connected to the VM whose rules
> the user intended to edit (normally, of course, there will be just one
> FirewallVM in the chain). So, e.g.:
>
> work -> work-vpn -> firewallvm -> netvm
This is not exactly true. Every ProxyVM have firewall.
Because we do NAT in every ProxyVM, it is impossible to distinguish
packets from different AppVMs anywhere else but ProxyVM _directly_
connected to AppVM. Because of this, firewall rules are applied in first
ProxyVM in chain - here work-vpn - regardless of its name, additional
function etc.
> We should automatically find firewallvm and send the user-created
> firewalling rules to that VM via xenstore. We should also warn the user
> in case no firewallvm was found in the whole chain! Normally such
> scenario would not occur for any AppVM (because we will provide default
> netvm and firewallvm and ensure to connect all AppVMs to the default
> firewallvm on create), but it might be the case if user manually started
> modyfing the configuration (via qvm-pref). Also, some VMs will not have
> FirewallVM by definition, e.g. NetVMs, FirewallVMs, or Dom0. In each of
> those case, the manager should display an appropriate message and not
> open the fw editor. Otherwise, i.e. if we found the FirewallVM we should
> display its name in the fw editor somewhere.
--
Pozdrawiam / Best Regards,
Marek Marczykowski | RLU #390519
marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl
Joanna Rutkowska
> On 03/16/11 12:17, Joanna Rutkowska wrote:
>> Now, whenever the user clicks the firewall edit button in the manager,
>> we should find the closest FirewallVM connected to the VM whose rules
>> the user intended to edit (normally, of course, there will be just one
>> FirewallVM in the chain). So, e.g.:
>>
>> work -> work-vpn -> firewallvm -> netvm
>
> This is not exactly true. Every ProxyVM have firewall.
> Because we do NAT in every ProxyVM, it is impossible to distinguish
> packets from different AppVMs anywhere else but ProxyVM _directly_
> connected to AppVM. Because of this, firewall rules are applied in first
> ProxyVM in chain - here work-vpn - regardless of its name, additional
> function etc.
>
Ah, indeed. Ok, so we assume that the first _ProxyVM_ to which a VM is
connect is also its FirewallVM. Of course, we must ensure it's a
ProxyVM, as it might be possible that some VMs will be connected
directly to a NetVM -- in that case we want to display a warning to the
user in the f/w editor (i.e. always if !vm->netvm_vm.is_proxy_vm()).
I think we still want to create a default firewallvm -- if the user
decides to use some VPN, then the user would likely further configure
this VPN to connect directly to a NetVM without using the default
firewallvm -- but that's not a problem, because we will always be
providing rules to the proper ProxyVM, right?
joanna.
Joanna Rutkowska
Or perhaps we should assume that the _last_ _ProxyVM_ is the enforcing
firewallVM? This would allow e.g. for using one trusted firewallVM, and
less trusted VPN connect to it (this is when we don't trust VPN client)
so much, e.g.:
work -> workVPN -> default firewall -> NetVM
In the default configuration it would make no difference, and in case
the use trusts VPN and doesn't want to add another firewall VM into the
chain it sill would be fine.
?
joanna.
Marek Marczykowski
There we cannot apply different rules for different AppVMs.
> This would allow e.g. for using one trusted firewallVM, and
> less trusted VPN connect to it (this is when we don't trust VPN client)
> so much, e.g.:
>
> work -> workVPN -> default firewall -> NetVM
>
> In the default configuration it would make no difference, and in case
> the use trusts VPN and doesn't want to add another firewall VM into the
> chain it sill would be fine.
This can be done by setting firewall rules for workVPN. Well, currently
not supported...
Joanna Rutkowska
> Dnia 2011-03-16, śro o godzinie 14:18 +0100, Joanna Rutkowska pisze:
>> Ah, indeed. Ok, so we assume that the first _ProxyVM_ to which a VM is
>> connect is also its FirewallVM. Of course, we must ensure it's a
>> ProxyVM, as it might be possible that some VMs will be connected
>> directly to a NetVM -- in that case we want to display a warning to
>> the user in the f/w editor (i.e. always if !
>> vm->netvm_vm.is_proxy_vm()).
>
> ie. creating firewall rules directly in netvm or dom0 if a firewalled VM
> happens to be connected to.
>
> We could then just create rules in whichever netvm/fwvm/dom0 the
> firewalled VM is connected to.
> This approach may really simplify things for trivial cases.
>
>
NetVM is generally untrusted, and we want our FirewallVM to be trusted
-- this is because those firewalling rules are to save the user from
making stupid mistakes (e.g. opening an emailed URL link in the work
domain). So, we want to separate firewall enforcing from potentially NetVM.
When NetVM == Dom0, then it makes no sense, because if Dom0 is
compormised then everything else is compromised. Of course this just
shows how insecure such configuration is, but well... for people that
have not VT-d hardware there is little we can do (and all other current
OSes do the same). We sill provide some value, because inter-VM
isolation is very good even on non-VT-d system.
joanna.
Tomasz Sterna
> connect is also its FirewallVM. Of course, we must ensure it's a
> ProxyVM, as it might be possible that some VMs will be connected
> directly to a NetVM -- in that case we want to display a warning to
> vm->netvm_vm.is_proxy_vm()).
What are disadvantages of treating NetVM and Dom0NetVM as Firewall too?
ie. creating firewall rules directly in netvm or dom0 if a firewalled VM
happens to be connected to.
We could then just create rules in whichever netvm/fwvm/dom0 the
firewalled VM is connected to.
This approach may really simplify things for trivial cases.
--
Tomasz Sterna
Instant Messaging Consultant : Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
Tomasz Sterna
> In this case there is no point in separating firewalling code from
> Dom0 (Dom0 is most trusted anyway). So in this case both NetVM and
> FirewallVM functionality should be in Dom0.
>
> Now, this complicates the design a bit, forcing us to maintain
> essentially the same code in two places. So, perhaps it would be an
> attractive option to always use separate NetVM, even if user has no
> VT-d. After all we don't lose anything this way, right?
Let me summarize.
If you have VT-d in machine - the decision is no brainer. You go for
separate NetVM + FirewallVM scenario.
But if you don't, you gain a bit harder attack vector. And the question
is are you willing to trade some system resources (memory, CPU) to have
it. This ultimately is a user decision, right?
And as you said running NetVM costs not only resources but potential
stability issues, which again is a user decision if one is willing to
take the risk.
So, at least for now I think we need to support both AppVM+FwVM+NetVM
and AllInOneDom0 scenarios.
Zrubecz Laszlo
On 16 March 2011 12:17, Joanna Rutkowska <joa...@invisiblethingslab.com> wrote:
> In Qubes Beta 1 we're introducing firewalling and generally a concept of
> a ProxyVM, that can also be used as e.g. a VPN gateway for select AppVMs
> (e.g. allow work-related domains to connect to the corporate intranet).
> This can be now _effectively_ implemented thanks to our new template
> sharing scheme implemented by Marek (BTW, Marek can you write some
> description of this template sharing scheme in the Wiki?).
>
> There are a few things I would like to discuss regarding this new
> networking scheme.
>
> Let's first assume the (much more preferred) scenario when the user has
> a VT-d capable laptop and uses a separate NetVM.
>
> In that case we should automatically (by installer's firstboot script I
> think) create the _default_ NetVM and FirewallVM:
>
> qvm-create netvm --net --label red
> qvm-create firewallvm --proxy --label green
>
> If the user wanted more NetVMs, e.g. wanted to have two separate NetVMs
> for each NIC, then the user would need to do that manually from command
> line (via qvm-create and qvm-pref). Right now such operation will not be
> supported from our gui manager.
It would be nice to separate the LAN and wifi adapters from each other.
> Now, whenever the user clicks the firewall edit button in the manager,
> we should find the closest FirewallVM connected to the VM whose rules
> the user intended to edit (normally, of course, there will be just one
> FirewallVM in the chain). So, e.g.:
>
> work -> work-vpn -> firewallvm -> netvm
I wonder why you are thinking about more than one firewall VM?
If the firewall means a packet filter (even if its an application
level one) we need only one, with as many interface as we need:
- 1 interface for every UserVM
- 1 interface for every netVM
Of course in this case we need more complicated iptables rules but it
is much better than we have more firewall VMs!
I'm also wonder why you put the VPN VM before the packetfilter? If
you do the packetfilter only see the encrypted traffic and there is
nothing to do with it.... Even more, why do you separate the
packetfilter from a VPN client? (we only talking about a VPN client,
right?) So I would do this way:
work VM -
- netVM1
Other VM - THE firewall VM (with or without VPN) - netVM2
More VMS - - netVMx
> Now, this complicates the design a bit, forcing us to maintain
> essentially the same code in two places. So, perhaps it would be an
> attractive option to always use separate NetVM, even if user has no
> VT-d. After all we don't lose anything this way, right?
>
> Or do we? I see two potential problems in using NetVM on non-VT-d systems:
>
> - The malfunctioning driver in NetVM might crash the system if it
> incorrectly handles pfn->mfn memory translations, or assume some exotic
> access to PCI config space (but this can be addressed via the permissive
> flag -- we will argue that it doesn't decrease security even in case of
> VT-d system -- a topic for a separate article though)
A non VT-d capable system is conpletly out of focus I think. At this
point the whole project is beta, and all the new hardware are VT-d
capable... And if somebody want to use Qubes, will want security...
And will choose a VT-d capable system.
(I'm saying this even if my current lapton does not support it -
thanks to Fujitsu Siemens BIOS)
> - There is a known problem with suspend/resume operation, which might
> lead to memory fragmentation and might result in the driver in NetVM not
> being able to allocate continue DMA buffers, and so failing to enable
> the interface after resume.
Suspend/resume feature is insecure anyway. If someone cares about
security never suspend his laptop.
--
Zrubi
Joanna Rutkowska
/.../
> It would be nice to separate the LAN and wifi adapters from each other.
>
In Qubes Beta 1 such config would be very easy to setup (thanks to our
new scheme for template sharing).
>
>> Now, whenever the user clicks the firewall edit button in the manager,
>> we should find the closest FirewallVM connected to the VM whose rules
>> the user intended to edit (normally, of course, there will be just one
>> FirewallVM in the chain). So, e.g.:
>>
>> work -> work-vpn -> firewallvm -> netvm
>
> I wonder why you are thinking about more than one firewall VM?
>
As already discussed in this thread, we want the first proxy VM to also
do the firewalling. Other options are not possible because of NAT that
each Proxy VM doesn.
> If the firewall means a packet filter (even if its an application
> level one) we need only one, with as many interface as we need:
> - 1 interface for every UserVM
> - 1 interface for every netVM
>
A user might want to have more than one NetVM, and more than one Proxy
VM (e.g. VPN). Even if using one NetVM (the common case), still it makes
sense to have more than one Proxy VMs -- e.g. all my work-related VMs
could use WorkVPN, while my other VMs could use something else (e.g.
TorVPN).
> I'm also wonder why you put the VPN VM before the packetfilter?
We don't, see above.
/.../
>
> A non VT-d capable system is conpletly out of focus I think. At this
> point the whole project is beta, and all the new hardware are VT-d
> capable... And if somebody want to use Qubes, will want security...
> And will choose a VT-d capable system.
> (I'm saying this even if my current lapton does not support it -
> thanks to Fujitsu Siemens BIOS)
>
Qubes can still offer significant security advantage (comaparing to
other OSes) even on non VT-d system (and even non-VT-x)!
joanna.
Marek Marczykowski
>> lead to memory fragmentation and might result in the driver in NetVM not
>> being able to allocate continue DMA buffers, and so failing to enable
>> the interface after resume.
> Suspend/resume feature is insecure anyway. If someone cares about
> security never suspend his laptop.
Yes, but it is convenient... I think it could be done enough securely
for most people:
On my laptop I have encrypted only /var/lib/qubes/appvms (in dom0) -
there are sensitive data. Sometimes sensitive data will be also in
servicevms (VPN keys, wifi credentials, etc) - then I will also encrypt
this directory.
Before suspend:
1. pause every VM
2. erase encryption keys from RAM (suspend appvm device-mapper)
After resume:
1. prompt for encryption password, unlock appvm device-mapper
2. resume VMs
The only problem is NetVM, which didn't survive suspend, as Joanna
mentioned above.
Alternative way to achieve similar effect is to save VMs state (xm save)
to encrypted partition, poweroff system (dom0). After poweron, resume
VMs, restart qubes_gui(d), setup network connections between VMs, and
maybe some additional steps.
This operation is somehow complicated, takes (much?) longer than simple
suspend, but could be more secure.
The goal (for me) is to keep state of running applications in AppVMs.
Joanna Rutkowska
>> lead to memory fragmentation and might result in the driver in NetVM not
>> being able to allocate continue DMA buffers, and so failing to enable
>> the interface after resume.
> Suspend/resume feature is insecure anyway. If someone cares about
> security never suspend his laptop.
>
Well, without _proper_ trusted boot any kind of shutdown is totally
insecure, and I would argue that suspend/resume is more secure in that
case than doing a full system shutdown. Evil Maid attack demonstrates
why it is so. (Coldboot is much more difficult and much less reliable
than Evil Maid, and DMA attacks from untrusted devices can be addressed
via VT-d)
Today there are *no* desktop OSes that would do proper trusted boot,
which could prevent the simplest Evil Maid attacks. None. Zero. Null.
Nil. Not even Qubes currently.
So, again, there is no reason not to use suspend/resume today -- it's
the most preferred way to shutdown your system in fact, before we get
proper trusted boot (in Qubes 2.0).
joanna.
Laszlo Zrubecz
> Well, without _proper_ trusted boot any kind of shutdown is totally
> insecure, and I would argue that suspend/resume is more secure in that
> case than doing a full system shutdown. Evil Maid attack demonstrates
> why it is so. (Coldboot is much more difficult and much less reliable
> than Evil Maid, and DMA attacks from untrusted devices can be addressed
> via VT-d)
I'm agree there is no way to defend such a thing today.
The worst case: that you are forced to unlock it... and you will do
it. I'm sure. Of course in this case you will definietly know that
your comuter is compromised
> So, again, there is no reason not to use suspend/resume today -- it's
> the most preferred way to shutdown your system in fact, before we get
> proper trusted boot (in Qubes 2.0).
If you 'just' lost your laptop (i think this is a very common case),
there is a huge difference between a suspended and a comletly shutted
down machine.
If I'm wrong, please tell me where to read about.
Thanks.
--
Zrubi
Joanna Rutkowska
Well yes, but it's just that people do not accidentally _lose_ their
laptops all time. At the same time people constantly _leave_ their
laptops unattended, especially while traveling... I have done it
hundreds of times myself. If you leave it powered down, you never know
if you got it EvilMaided or not, while you were away. And what is
worrying is that this attack is so simple and reliable in practice.
joanna.
Peter Moody
Will Drewry
Well that's not entirely true :) The "evil maid" attack[1] falls
under the threat model for Google's Chrome OS which is out there
today, just not widely (since it does require matching hardware: the
Cr-48).
Of course, even _proper_ trusted boot only helps with the truly
opportunistic attacker, not a more dedicated/targeted one. (The TCG
does not include physical attacks in the thread model for the TPM so
if they crack the case on your laptop, it's still game over if they
have the tools/knowledge.) But that's probably a different
discussion.
Anyway, that statement drew me in, but I'd be happy to
discuss/point-to-relevant-docs the work done on chrome os for these
scenarios. And it'd be great if some of the code/design work
happened to be useful to Qubes development as well (the Linux-side of
things was designed with a tboot world in mind too it isn't too
foreign).
cheers!
will
[1] opportunistic cold boot attacks are also included
Joanna Rutkowska
> On Wed, Mar 23, 2011 at 4:55 AM, Joanna Rutkowska
> <joa...@invisiblethingslab.com> wrote:
>>
>>
>> Today there are *no* desktop OSes that would do proper trusted boot,
>> which could prevent the simplest Evil Maid attacks. None. Zero. Null.
>> Nil. Not even Qubes currently.
>>
>
> Well that's not entirely true :) The "evil maid" attack[1] falls
> under the threat model for Google's Chrome OS which is out there
> today, just not widely (since it does require matching hardware: the
> Cr-48).
>
Interesting... How do you authorize to the user? I.e. how does the user
know it's the original code that asks for the disk decryption passphrase?
> Of course, even _proper_ trusted boot only helps with the truly
> opportunistic attacker, not a more dedicated/targeted one. (The TCG
> does not include physical attacks in the thread model for the TPM so
> if they crack the case on your laptop, it's still game over if they
> have the tools/knowledge.) But that's probably a different
> discussion.
>
Yes, of course. Sophisticated physical attacks are always possible.
> Anyway, that statement drew me in, but I'd be happy to
> discuss/point-to-relevant-docs the work done on chrome os for these
> scenarios. And it'd be great if some of the code/design work
> happened to be useful to Qubes development as well (the Linux-side of
> things was designed with a tboot world in mind too it isn't too
> foreign).
>
Wait a sec -- are you saying that Cr-48 will support Intel TXT and VT-d?
Cheers,
joanna.
Joanna Rutkowska
> On 03/23/11 17:54, Will Drewry wrote:
>> On Wed, Mar 23, 2011 at 4:55 AM, Joanna Rutkowska
>> <joa...@invisiblethingslab.com> wrote:
>>>
>>>
>>> Today there are *no* desktop OSes that would do proper trusted boot,
>>> which could prevent the simplest Evil Maid attacks. None. Zero. Null.
>>> Nil. Not even Qubes currently.
>>>
>>
>> Well that's not entirely true :) The "evil maid" attack[1] falls
>> under the threat model for Google's Chrome OS which is out there
>> today, just not widely (since it does require matching hardware: the
>> Cr-48).
>>
>
> Interesting... How do you authorize to the user? I.e. how does the user
> know it's the original code that asks for the disk decryption passphrase?
>
s/authorize/authenticate
>> Of course, even _proper_ trusted boot only helps with the truly
>> opportunistic attacker, not a more dedicated/targeted one. (The TCG
>> does not include physical attacks in the thread model for the TPM so
>> if they crack the case on your laptop, it's still game over if they
>> have the tools/knowledge.) But that's probably a different
>> discussion.
>>
>
> Yes, of course. Sophisticated physical attacks are always possible.
>
>> Anyway, that statement drew me in, but I'd be happy to
>> discuss/point-to-relevant-docs the work done on chrome os for these
>> scenarios. And it'd be great if some of the code/design work
>> happened to be useful to Qubes development as well (the Linux-side of
>> things was designed with a tboot world in mind too it isn't too
>> foreign).
>>
>
> Wait a sec -- are you saying that Cr-48 will support Intel TXT and VT-d?
>
> Cheers,
> joanna.
>
>> cheers!
>> will
>>
>> [1] opportunistic cold boot attacks are also included
>
>
j.
Will Drewry
<joa...@invisiblethingslab.com> wrote:
> On 03/23/11 17:54, Will Drewry wrote:
>> On Wed, Mar 23, 2011 at 4:55 AM, Joanna Rutkowska
>> <joa...@invisiblethingslab.com> wrote:
>>>
>>>
>>> Today there are *no* desktop OSes that would do proper trusted boot,
>>> which could prevent the simplest Evil Maid attacks. None. Zero. Null.
>>> Nil. Not even Qubes currently.
>>>
>>
>> Well that's not entirely true :) The "evil maid" attack[1] falls
>> under the threat model for Google's Chrome OS which is out there
>> today, just not widely (since it does require matching hardware: the
>> Cr-48).
>>
>
> Interesting... How do you authorize to the user? I.e. how does the user
> know it's the original code that asks for the disk decryption passphrase?
The devices are modal (with a physical switch under the battery):
verified (trusted) or developer (not). If the device is verified,
then the system image is integrity checked throughout boot up to the
login screen. The system image is read-only and static with mutable
data either in a separate location (with the working assumption that
an attacker could modify it in the worst case) or in a per-user
encrypted directory.
The nice part about this is that we don't have to conflate
confidentiality with authenticity. Nothing on the system image is
secret so we can just integrity check it and move on. It also
decouples user authentication from the boot path. Being able to do
this is a byproduct of not allowing executable code outside of the
system image, but the same policies could apply to a hypervisor
rootfs, for instance.
Anyway - if the system was booted in verified mode, all should proceed
normally to the login screen where the user can pick their picture and
sign in to the device. Their passphrase then takes a joyride through
the TPM to unwrap the disk crypto key. If the system was in developer
mode, then a firmware-enforced warning was displayed to inform the
user that the system image may not be verified/verifiable prior to
booting the OS itself.
[As an additional layer, if you transition to developer mode by
flicking the switch and rebooting, the tpm gets cleared and the ram
zeroed in the firmware. In addition, there's no USB boot support in
verified mode, so you'll have to go through the transition to get
access to the system memory/etc (without a runtime compromise).]
>
>> Of course, even _proper_ trusted boot only helps with the truly
>> opportunistic attacker, not a more dedicated/targeted one. (The TCG
>> does not include physical attacks in the thread model for the TPM so
>> if they crack the case on your laptop, it's still game over if they
>> have the tools/knowledge.) But that's probably a different
>> discussion.
>>
>
> Yes, of course. Sophisticated physical attacks are always possible.
>
>> Anyway, that statement drew me in, but I'd be happy to
>> discuss/point-to-relevant-docs the work done on chrome os for these
>> scenarios. And it'd be great if some of the code/design work
>> happened to be useful to Qubes development as well (the Linux-side of
>> things was designed with a tboot world in mind too it isn't too
>> foreign).
>>
>
> Wait a sec -- are you saying that Cr-48 will support Intel TXT and VT-d?
Intel TXT, and especially, VT-d would be really nice to have, but the
processor on the cr-48 doesn't support them.
However, we do have our own firmware chip which has a read-only
component. That acts as our (static) root of trust to avoid needing
TXT or any sort of dynamic root of trust on that hardware (though
there are complexities with that approach). Once the "verified boot"
flow reaches the Linux kernel, it hands off a hash value which is used
to verify the root filesystem's integrity (via a hash tree). This
last step will play perfectly nicely with TXT/tboot, but I haven't had
the cycles to integrate that flow into the less-hardware-dependent
Chromium OS. I suspect that the rootfs verification bit might also be
useful to Qubes and other distributions with tightly managed system
images.
Plenty of work still left to do of course :)
cheers!
will
(Almost forgot, we don't expose any direct dma ports on the outside of
the device which is helpful for the firewire-style attack. It'll be
nicer when vt-d behavior can be used to blanket protect against
peripheral dma attacks, though.)
Joanna Rutkowska
So, the authentication process (machine to the user) is based on
displaying the user's trusted picture? Which itself is stored on disk
encrypted with a key that is extracted (unsealed) from the TPM only if
the whole SRTM chain was correct?
If so, then I would have to humbly admit I was wrong with the statement
above! (although you're cheating a bit by being able to control all the
hardware as well :P) Although not perfect, I personally believe that the
use of trusted pictures with trusted boot is a reasonable way to
increase the difficulty of Evil Maid attacks significantly, without
sacrificing the usability.
/.../
>> Wait a sec -- are you saying that Cr-48 will support Intel TXT and VT-d?
>
> Intel TXT, and especially, VT-d would be really nice to have, but the
> processor on the cr-48 doesn't support them.
>
/.../
> (Almost forgot, we don't expose any direct dma ports on the outside of
> the device which is helpful for the firewire-style attack. It'll be
> nicer when vt-d behavior can be used to blanket protect against
> peripheral dma attacks, though.)
Yes, this is an important point and you're very lucky you could control
your whole hardware.
Still, an attacker who managed to somehow compromise one of your drivers
(kernel mode in general) could theoretically reflash a PCI/e device and
have it perform malicious DMAs during your next boot. (In practice this
might be very difficult). That's one area where TXT-based boot could be
superior over static boot. And, of course, for mere mortal ones, who
don't control all the firmware (and don't want to trust the BIOS), TXT
is the only way to go...
Thanks for dropping by!
joanna.
Will Drewry
Not quite - though I realized after I hit send that, if read in this
context, it might come across that way!
The user only has negative indicators. By default, the system image
is integrity checked and all is well. So if it has been tampered with,
they will be notified by:
1. a warning if someone switched them to developer mode (and have the
mutable data reset)
2. force boot over to a hardware-backed system recovery flow (or to an
old known-good image if possible)
The login screen data itself is not (yet) sealed against the TPM.
It's just an account picker for who has an account on the system
(read: mutable). Even so, if it had a trusted image that was only
shown on a trusted boot, it could be reconstructed by a local
attacker. For instance, the attacker could take a picture (with a
phone camera :) by booting up once, then reinstall the device
bootloader & fake-out-normal-pcrs, and insert the
copy-of-the-trusted-picture on the newly minted malicious boot path.
Even with encryption of the image, it roughly reduces to showing a
familiar login screen or not since the data is visible to the
attacker. Adding in a pre-image password to go with a post-image
password would resolve that, but usability suffers quite a bit, imo.
At that point, just start carrying a usb boot dongle :p
(Might also be worth noting that, chrome os doesn't rely on the TPM
for SRTM hashing for a couple of reasons. We do extend one PCR (to
indicate modality) and rely on our static chain of trust to get to a
good system - and otherwise we clear the tpm. Similar effect, but a
different path. The system image is also integrity checked on-the-fly
so it's possible that a modified block won't be noticed until it is
attempted to be used - not right at boot.)
> If so, then I would have to humbly admit I was wrong with the statement
> above! (although you're cheating a bit by being able to control all the
> hardware as well :P) Although not perfect, I personally believe that the
> use of trusted pictures with trusted boot is a reasonable way to
> increase the difficulty of Evil Maid attacks significantly, without
> sacrificing the usability.
>
I'll accept the charges of cheating, so I can go back into hiding
until I have tboot working for non-Chrome hardware :)
With my clarification above, though, you may disagree that we're
meeting the bar. Since we aren't able to attest (to the user) that
all of the mutable data on the system is tamper-free, there is still
some room for discussion. Though, I have some obvious ideas/plans to
resolve it, like by sealing a key to the hardware mode-tied PCR.
Unfortunately, disk encryption is not quite the same as disk integrity
checking, but it raises the bar significantly!
> /.../
>
>>> Wait a sec -- are you saying that Cr-48 will support Intel TXT and VT-d?
>>
>> Intel TXT, and especially, VT-d would be really nice to have, but the
>> processor on the cr-48 doesn't support them.
>>
>
> /.../
>
>> (Almost forgot, we don't expose any direct dma ports on the outside of
>> the device which is helpful for the firewire-style attack. It'll be
>> nicer when vt-d behavior can be used to blanket protect against
>> peripheral dma attacks, though.)
>
> Yes, this is an important point and you're very lucky you could control
> your whole hardware.
>
> Still, an attacker who managed to somehow compromise one of your drivers
> (kernel mode in general) could theoretically reflash a PCI/e device and
> have it perform malicious DMAs during your next boot. (In practice this
> might be very difficult). That's one area where TXT-based boot could be
> superior over static boot. And, of course, for mere mortal ones, who
> don't control all the firmware (and don't want to trust the BIOS), TXT
> is the only way to go...
Yeah - validating peripheral firmware is hard (in general), and
without memory curtaining it's nearly impossible to have solid
defenses against modified/malicious peripheral firmware attacks.
> Thanks for dropping by!
Thanks for the discussion!
will
Joanna Rutkowska
/.../
>>
>> So, the authentication process (machine to the user) is based on
>> displaying the user's trusted picture? Which itself is stored on disk
>> encrypted with a key that is extracted (unsealed) from the TPM only if
>> the whole SRTM chain was correct?
>
> Not quite - though I realized after I hit send that, if read in this
> context, it might come across that way!
>
> The user only has negative indicators. By default, the system image
> is integrity checked and all is well. So if it has been tampered with,
> they will be notified by:
> 1. a warning if someone switched them to developer mode (and have the
> mutable data reset)
> 2. force boot over to a hardware-backed system recovery flow (or to an
> old known-good image if possible)
>
If I switch the device into the developer's mode and install ordinary
Linux, will there be any negative indicators? Will the _firmware_
display some warning before handing off to my custom software?
If not, than the attack is that I make a copy of the user's HDD, and
then switch to devel mode, install my custom Linux that displays a fake
looking login screen and then communicates the passphrase to me over the
net. I can now decrypt the victim's HDD.
If the firmware displays a warning message, then the attack is that I
replace the user's original Cr-48 with my copy that I prepared in
advance at home that has custom firmware (reflashed perhaps using EEPROM
programmer) and software installed and that displays the fake login
screen and communicates the passphrase to me over the net.
This would be somehow more complicated than a simple EM attack, but
still on the reasonable side (e.g. against business users traveling to
China).
Prevention: put unique conference stickers on your CR-48! ;)
> The login screen data itself is not (yet) sealed against the TPM.
> It's just an account picker for who has an account on the system
> (read: mutable). Even so, if it had a trusted image that was only
> shown on a trusted boot, it could be reconstructed by a local
> attacker. For instance, the attacker could take a picture (with a
> phone camera :) by booting up once, then reinstall the device
> bootloader & fake-out-normal-pcrs, and insert the
> copy-of-the-trusted-picture on the newly minted malicious boot path.
> Even with encryption of the image, it roughly reduces to showing a
> familiar login screen or not since the data is visible to the
> attacker. Adding in a pre-image password to go with a post-image
> password would resolve that, but usability suffers quite a bit, imo.
> At that point, just start carrying a usb boot dongle :p
>
Yes, of course, it's possible to capture the unseealed picture with a
camera (I assume the VGA output is disabled at this stage) and mount
Evil Maid that would be using it. But I would argue that in practice it
would be very difficult to take a good quality photo of a picture shown
on the screen, so that I could not tell the difference. I'm quite
sensitive to subtle changes in aesthetics of the screen.
For those more paranoid (or visually impaired) we discuss some more
secure options of how to handle such authentication in Qubes
architecture spec [1]. But, I don't think that your proposed scheme with
pre- and post-image passphrases would increase the difficulty of the
attack much, as they could be attacked using a 2-stage EM attack.
Well ok, generally this problem is not solvable. In the most extreme
scenario (that involves using some challenge response protocol for
authentication and external device for authentication) the attacker can
always resort to a 2-laptop scheme (like the one I discussed above),
where the user communicating with a fake laptop which itself acts as a
proxy to the original laptop that is in the hands of the attacker and
that is used to perform authentication challenge-response. Network
connectivity at the time of pre-boot is needed for this type of attack
(and this makes it so much more difficult than the previously mentioned
attack), but this could hardly be prevented if the user is operating a
fake hardware (it could have e.g. non-functional WiFi power switch). But
this would be a very sophisticated and expensive attack, so I think we
could ignore it :)
[1] http://qubes-os.org/files/doc/arch-spec-0.3.pdf
> (Might also be worth noting that, chrome os doesn't rely on the TPM
> for SRTM hashing for a couple of reasons. We do extend one PCR (to
> indicate modality) and rely on our static chain of trust to get to a
> good system - and otherwise we clear the tpm. Similar effect, but a
> different path. The system image is also integrity checked on-the-fly
> so it's possible that a modified block won't be noticed until it is
> attempted to be used - not right at boot.)
>
So, have you already implemented the signed-only block device? Or is it
on the fs-level not on the block level? We would love to have such a
thing for Qubes 2.0 for our untrusted storage domain...
Cheers,
joanna.
Will Drewry
<joa...@invisiblethingslab.com> wrote:
> On 03/23/11 23:43, Will Drewry wrote:
> /.../
>>>
>>> So, the authentication process (machine to the user) is based on
>>> displaying the user's trusted picture? Which itself is stored on disk
>>> encrypted with a key that is extracted (unsealed) from the TPM only if
>>> the whole SRTM chain was correct?
>>
>> Not quite - though I realized after I hit send that, if read in this
>> context, it might come across that way!
>>
>> The user only has negative indicators. By default, the system image
>> is integrity checked and all is well. So if it has been tampered with,
>> they will be notified by:
>> 1. a warning if someone switched them to developer mode (and have the
>> mutable data reset)
>> 2. force boot over to a hardware-backed system recovery flow (or to an
>> old known-good image if possible)
>>
>
> If I switch the device into the developer's mode and install ordinary
> Linux, will there be any negative indicators? Will the _firmware_
> display some warning before handing off to my custom software?
It'll always show the warning in firmware before hand off to an unknown kernel.
> [...]
>
> If the firmware displays a warning message, then the attack is that I
> replace the user's original Cr-48 with my copy that I prepared in
> advance at home that has custom firmware (reflashed perhaps using EEPROM
> programmer) and software installed and that displays the fake login
> screen and communicates the passphrase to me over the net.
Yeah - then it reduces to just booting up the person's device once to
make sure you have similar login users and pictures. It's not
dissimilar to the txt attack though: boot once, steal a picture, then
swap in your dupe and preload the picture. (Or even swap out/reimage
the BIOS and don't take a boot path that uses TXT.)
It's a hard problem to be able to securely attest local machine state
to the physical user! [As you lay out below!]
:)
yeah - usb tokens, etc provide so more options there, but also add
more complexity. I look forward to seeing what you finally settle on
for qubes.
> [1] http://qubes-os.org/files/doc/arch-spec-0.3.pdf
>
>> (Might also be worth noting that, chrome os doesn't rely on the TPM
>> for SRTM hashing for a couple of reasons. We do extend one PCR (to
>> indicate modality) and rely on our static chain of trust to get to a
>> good system - and otherwise we clear the tpm. Similar effect, but a
>> different path. The system image is also integrity checked on-the-fly
>> so it's possible that a modified block won't be noticed until it is
>> attempted to be used - not right at boot.)
>>
>
> So, have you already implemented the signed-only block device? Or is it
> on the fs-level not on the block level? We would love to have such a
> thing for Qubes 2.0 for our untrusted storage domain...
It's block level (to avoid fs level attacks) and built on device mapper.
Docs:
http://git.chromium.org/gitweb/?p=kernel.git;a=blob;f=Documentation/device-mapper/dm-verity.txt
http://git.chromium.org/gitweb/?p=kernel.git;a=blob;f=Documentation/device-mapper/dm-bht.txt
http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
Source:
http://git.chromium.org/gitweb/?p=kernel.git;a=blob;f=drivers/md/dm-verity.h
http://git.chromium.org/gitweb/?p=kernel.git;a=blob;f=drivers/md/dm-verity.c
http://git.chromium.org/gitweb/?p=kernel.git;a=blob;f=drivers/md/dm-bht.c
In order to use it at boot without an initramfs, there are a few out
of kernel tree patches (to allow dm="..." on the commandline with the
verifying hash), but I'm hoping those patches and the device mapper
target will be acceptable to upstream after we finish cleaning up the
code and ensure the interfaces have stabilized.
Oh yeah - the commandline half of it is here (and it should build
outside of the chromium os build environment):
http://git.chromium.org/gitweb/?p=dm-verity.git;a=tree
cheers!
will