[OLPC Security] Bitfrost and dual-boot

[Jameson "Chema" Quinn]

Bitfrost protections are meaningless if they only work half of the time. If
you have a dual-boot box, how can one OS keep its protections even if the
other half is considered untrusted code? This is of course even harder
without passwords.

However, it is not impossible, with help from the firmware. Here are the
beginnings of one scheme:

An unactivated XO would have a blank space in the firmware for a key.
During activation, the OS would generate an RSA key and give it to the
firmware. It would also make any backups of that key that were necessary -
During boot, the XO would enter one of three states:
If booting with a signed OS, it would be "key-responsive". The
firmware would, on a special system call, encrypt/decrypt one block of data
using the private key. (one block is enough to sign a hash or encrypt a
session key). This system call would be available only to root. There would
be no way, even for root, to read the key itself.
If booting with an unsigned OS, it would be "key-unresponsive".
There would be no access to the key at all.
If booting with a particular cheat code (hardware buttons held
down), it would be "key-permissive". The private key could be read or
written.

Also, any OS in local flash would have its core files (kernel and anything
that could execute as root) in protected flash, other OS's would not be able
to write to this flash.

Those with a developer key would be able to mark an OS on their machine as
"signed".

With this system in place, it would be possible to protect against the worst
abuses from the untrusted OS. It might still be able to read or write in the
other OS's data, but the other OS would use encryption to keep private data
from being read, and signatures to keep invalid data from leading to
escalated privileges. So the worst the rogue OS could inflict would be
dataloss; the temptations for virus writers would be minimized.

What do people think? Is this a real problem? Is my hand-waving the
beginnings of a solution, or why not?

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080528/d7f313fd/attachment.htm

[Benjamin M. Schwartz]

What are you trying to prevent?

- --Ben

[Jameson "Chema" Quinn]

Actually, the goals are more limited. Say you have dual-boot; OS 1 has
bitfrost, OS 2 does not. Things OS 2 should not do:

1. Read private files from OS 1.
1a. Read encryption key from OS 1, thus subverting all security which that
key gives. This, in particular, should be avoided.
1a(i). By reading unitialized memory, snoop passwords which OS 1 had only in
volatile memory. This threat was not mentioned in my initial email because
such passwords are not envisioned by Bitfrost as being part of sugar - it is
the one case where OS 1 could be windows. However, it is easy enough to
prevent by clearing volatile memory on reboot. This would give the XO, which
has soldered-on RAM, better security characteristics than any laptop I know
of (until the macbook air updates its firmware).

2. By writing to OS 1's file system, subvert the bitfrost security within OS
1 itself, such that even if OS 2 is later deleted, malware can now do bad
things inside OS 1.
2a. By simple changes to files that should be writeable within OS 1 - that
is, chmod on a data file, or changing a file of user-granted extra Bitfrost
privileges.
2b. By changes to files that could be read-only within OS 1 - that is, by
replacing the kernel or bitfrost-related code or binaries.
2c. Do 2a and/or 2b in such a way that they are not detectable, or not
fixable simply through a reinstall. In other words, I would like to be able
to say "I just removed a major trojan from my Windows, please rescan Sugar
to ensure that system files have not been changed" or, more simply,
"reinstall Sugar".

3. Cause denial of service by erasing or changing files necessary for OS 1
to run.

4. Cause dataloss by erasing or changing OS 1's data files.

5. Insert data into OS 1's journal by writing new data files.

...

I am only focused on preventing 1 and 2 here. In particular, I think that 1a
and 1a(i) are worth considering. Also, If 2b is deemed impractical to guard
against, 2 may be acceptably addressed only by 2a and 2c.

3 would be very hard to accomplish. However, security measures to prevent 2b
should also help mitigate the risks of 3.

5 is arguably even desirable, and it is impractical to allow 5 without
allowing 4, so these should not be considered.

...

Ivan, could you elaborate on why you think that this is not a "good
extension of the threat model"? Do you believe that these threats is not
real, or do you believe that it will be impossible to guard against them, or
other?

Jameson

On Wed, May 28, 2008 at 7:01 PM, Ivan Krsti? <

Post by Benjamin M. Schwartz
What are you trying to prevent?

He doesn't want one OS to be able to screw with files from another in a
dual-boot scenario. I don't think it's a good extension of the threat model.
--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | http://radian.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080529/c9ae52bf/attachment.htm

[Michael Stone]

if you run everything as user olpc and user olpc can become root without a
password, getting olpc is as good as getting root.

An arbitrary process running as user olpc should not be able to get root. My
impression is that it cannot, currently; am I wrong?

In recent builds, any process running as user OLPC can execute code as
uid 0 via the setuid-0 user-olpc-executable /usr/bin/sudo.

The security strategy underlying this (which no one is executing since
I'm off making releases) is to push system code (pieces of the sugar
shell, the telepathy connection managers, etc.) into their own UIDs.

Comments?

Michael

P.S. - In the future, please remember to CC the security@ list on this
sort of discussion. I'm sure that there are people on that list who
would like to comment but who also have no interest in following the
general development lists.

[Michael Stone]

Post by Michael Stone
In recent builds, any process running as user OLPC can execute code as
uid 0 via the setuid-0 user-olpc-executable /usr/bin/sudo.

A small correction: in recent builds, /bin/su is 04550 root/wheel, user
olpc is a member of wheel, and /usr/bin/sudo is a thin wrapper around
/bin/su.

Michael

[C. Scott Ananian]

Post by Michael Stone

Post by Michael Stone
In recent builds, any process running as user OLPC can execute code as
uid 0 via the setuid-0 user-olpc-executable /usr/bin/sudo.

A small correction: in recent builds, /bin/su is 04550 root/wheel, user
olpc is a member of wheel, and /usr/bin/sudo is a thin wrapper around
/bin/su.

And to elaborate: the idea is that untrusted code should not be
running as the 'olpc' user: 'olpc' is a trusted account. Activities
run/should be running as their own unique UUIDs, which are isolated
from the olpc account.

As to some other issues brought up:

* Windows runs from an SD card, but there is not much space left on
that SD card to store user files. User files are stored in NAND at
the moment. In the dual-boot scenario which OFW2 will enable, we will
either partition the NAND (likely also expand amount on onboard NAND),
or limit Windows to the storage on the SD card (probably necessitating
an increase in the size of the SD card). None of this has been
decided yet.

* It is worth separating out the various bitfrost protections.
Initial activation security is implemented by OFW; it doesn't matter
whether windows or linux is running after the firmware cedes control.
Other bitfrost protections are OS-dependent, and you are likely to
give up at least some security when you install Windows on the XO.
--scott

[Albert Cahalan]

Post by C. Scott Ananian
* Windows runs from an SD card, but there is not much space left on
that SD card to store user files. User files are stored in NAND at
the moment. In the dual-boot scenario which OFW2 will enable, we will
either partition the NAND (likely also expand amount on onboard NAND),
or limit Windows to the storage on the SD card (probably necessitating
an increase in the size of the SD card). None of this has been
decided yet.

Did I miss something? I was under the impression that the XO uses JFFS2 on
the NAND. If we're worried about Windows malware messing with files on the
NAND, won't they have to be able to mount the volume first? I only did a
quick google search, but I didn't find any Windows JFFS2 implementation.

First of all, malware can contain filesystem drivers. It's been done.
In this case, probably an existing Open Firmware or Linux kernel
jffs2 driver would be made to run in userspace.

Second of all, there won't be any need to worry about this issue.
Windows is using the NAND for itself. There is nearly zero chance
that Microsoft will be willing to share the NAND. It's about the same
chance as Microsoft being leveled by a large meteorite.

We'd be very lucky to keep Open Firmware at all. I can well
imagine even worse than losing Open Firmware.

[Bert Freudenberg]

Post by C. Scott Ananian

Post by Michael Stone

Post by Michael Stone
In recent builds, any process running as user OLPC can execute code as
uid 0 via the setuid-0 user-olpc-executable /usr/bin/sudo.

A small correction: in recent builds, /bin/su is 04550 root/wheel, user
olpc is a member of wheel, and /usr/bin/sudo is a thin wrapper around
/bin/su.

And to elaborate: the idea is that untrusted code should not be
running as the 'olpc' user: 'olpc' is a trusted account. Activities
run/should be running as their own unique UUIDs, which are isolated
from the olpc account.

so a python program written by the owner of the laptop won't run as
user
olpc?
what if they write it in the terminal activity using vi?

It does not matter how you write the program, but how you run it. If
you invoke a python script from the terminal, it runs as user olpc. If
you run it from a root shell, it is root. If it is an activity, it
runs with a freshly created user id (and a per-activity group id). See
~olpc/isolation ... Only some trusted activities run as user olpc
(Journal, Terminal, a few more I believe).

- Bert -

[C. Scott Ananian]

Post by C. Scott Ananian
And to elaborate: the idea is that untrusted code should not be
running as the 'olpc' user: 'olpc' is a trusted account. Activities
run/should be running as their own unique UUIDs, which are isolated
from the olpc account.

so a python program written by the owner of the laptop won't run as user
olpc?

A Pippy program will in general not run as 'olpc'.

what if they write it in the terminal activity using vi?

When you log in to the terminal you are running as olpc. You are a
trusted user. You can clearly write code and run it as yourself
(olpc), if you like. We would like to think that eventually you will
prefer to use Bitfrost-like capabilities (even on non-Sugar linux
platforms) to run your code by default as another user, just as best
practice says you shouldn't run most code you write as root.
--scott

[Albert Cahalan]

I do believe that, practically speaking, all of this is moot.
Windows uses both SD card storage and the NAND flash storage.
(NAND storage being what you'd hoped to protect)
The most you could protect would be the firmware itself, but
it is silly to imagine that a laptop would have OpenFirmware
when the NAND storage doesn't even have Linux.

The question was, how to protect Linux from Windows, in particular
from malware allowed in by Windows. (Or possibly from malware designed
into Windows, a "marketing" practice not unknown in the past.)
Protecting Windows-only machines is Microsoft's problem, not ours.
We can be quite certain that script kiddies and others will attack
Fedora and OFW on dual-boot XOs.

Why do you keep believing that dual-boot XOs will actually ship?

Windows XP is **using** the NAND storage.

There is no support for partitioning it. Even if both Linux and
OpenFirmware were to support such a thing, you'd have to get
Microsoft to agree to something that makes no business sense
at all.

Supposing you managed to get that miracle, you'd have to
convince countries to ship a system with two OSes that are
both about to run out of space. Microsoft will of course be
pushing for a better Windows experience, meaning all space
is allocated to Windows. (but this is theoretical, because you'd
need a miracle to get partitioned NAND support into Windows)

BTW, if NAND size were doubled, that would mean more NAND
available to Windows. If there were so much NAND available
that Windows had no use for it, Microsoft would find a way to
purposely waste the additional NAND.

Also, I think you completely misunderstand the market. The ability to
use Open FirmWare instead of a proprietary BIOS will be of intense
interest to all PC vendors. I expect OFW to sweep through most of the
market in no more than two or three years.

I can't imagine why. LinuxBIOS (now coreboot) didn't.
Even EFI didn't. Your wishes are not their wishes.

[Edward Cherlin]

Post by Albert Cahalan

I do believe that, practically speaking, all of this is moot.
Windows uses both SD card storage and the NAND flash storage.

I haven't seen it and you haven't seen it. What's your source? Are you
talking about the version in the Windows-only trials during the next
month or two?

Post by Albert Cahalan

(NAND storage being what you'd hoped to protect)
The most you could protect would be the firmware itself, but
it is silly to imagine that a laptop would have OpenFirmware
when the NAND storage doesn't even have Linux.

The question was, how to protect Linux from Windows, in particular
from malware allowed in by Windows. (Or possibly from malware designed
into Windows, a "marketing" practice not unknown in the past.)
Protecting Windows-only machines is Microsoft's problem, not ours.
We can be quite certain that script kiddies and others will attack
Fedora and OFW on dual-boot XOs.

Why do you keep believing that dual-boot XOs will actually ship?

Because Microsoft and OLPC announced dual-boot. Because Microsoft
can't buy XOs for resale, and OLPC has no intention of shipping
Windows-only XOs. Egypt wants dual-boot.

OK, so Microsoft could arrange to wipe out Linux after delivery. Then
what? Do you think that the world will stand still for that kind of
overt sabotage? I can't imagine OLPC signing a contract that would
allow it. I gather that you can. You're on crack, Albert.

Post by Albert Cahalan
Windows XP is **using** the NAND storage.
There is no support for partitioning it. Even if both Linux and
OpenFirmware were to support such a thing, you'd have to get
Microsoft to agree to something that makes no business sense
at all.

Sources, please. Who says what the dual-boot architecture will be? If
you won't be able to run Linux after the first time you run Windows,
as you seem to allege, in what sense is this dual-booting? Are Mitch
and Scott such technical idiots that they wouldn't spot this?

Post by Albert Cahalan
Supposing you managed to get that miracle, you'd have to
convince countries to ship a system with two OSes that are
both about to run out of space. Microsoft will of course be
pushing for a better Windows experience, meaning all space
is allocated to Windows. (but this is theoretical, because you'd
need a miracle to get partitioned NAND support into Windows)
BTW, if NAND size were doubled, that would mean more NAND
available to Windows. If there were so much NAND available
that Windows had no use for it, Microsoft would find a way to
purposely waste the additional NAND.

Also, I think you completely misunderstand the market. The ability to
use Open FirmWare instead of a proprietary BIOS will be of intense
interest to all PC vendors. I expect OFW to sweep through most of the
market in no more than two or three years.

I can't imagine why. LinuxBIOS (now coreboot) didn't.
Even EFI didn't. Your wishes are not their wishes.

Albert, I'm not talking to you any more until you start making sense.
Linux BIOS never booted any Windows other than 2000 (with ADLO), and
EFI isn't Open Source.

[Albert Cahalan]

Post by Edward Cherlin

Post by Albert Cahalan

I do believe that, practically speaking, all of this is moot.
Windows uses both SD card storage and the NAND flash storage.

I haven't seen it and you haven't seen it. What's your source?

As I said in a previous email, my source is Mitch on IRC.
It also just makes sense; I've long doubted the idea that
the NAND (a valuable resource) would just be wasted by
a Windows install.

Post by Edward Cherlin
Are you
talking about the version in the Windows-only trials during the next
month or two?

I'm talking about everything.

Use of NAND flash is a Windows feature that doesn't have
anything to do with the choice of firmware. Even if we get
to keep Open Firmware (a miracle), Windows can still use
the NAND flash.

Post by Edward Cherlin

Post by Albert Cahalan
Why do you keep believing that dual-boot XOs will actually ship?

Because Microsoft and OLPC announced dual-boot. Because Microsoft
can't buy XOs for resale, and OLPC has no intention of shipping
Windows-only XOs. Egypt wants dual-boot.

Many people have been burned by believing similar words.
None of that info is trustworthy, all of it can change at any
time, and at least one of the parties has a very long track
record of being ruthless.

Post by Edward Cherlin
OK, so Microsoft could arrange to wipe out Linux after delivery. Then
what? Do you think that the world will stand still for that kind of
overt sabotage? I can't imagine OLPC signing a contract that would
allow it. I gather that you can. You're on crack, Albert.

You're putting words in my mouth now.

Wiping out Linux after delivery is certainly possible.
It would take the form of a helpful suggestion that
the user format the D: volume to make more space.

I can't imagine that a contract would mention it.

Still, I don't expect this at all. It would allow children
to try Linux. Microsoft doesn't work that way.
The laptops will be Linux-free from the start.

Not that booting Linux would be easy anyway;
remember that it is very hard to remove the SD card.

Post by Edward Cherlin

Post by Albert Cahalan
Windows XP is **using** the NAND storage.
There is no support for partitioning it. Even if both Linux and
OpenFirmware were to support such a thing, you'd have to get
Microsoft to agree to something that makes no business sense
at all.

Sources, please.

Sure. See www.kernel.org if you want source, proving that
there is no support for partitioning. You can also get source
for Open Firmware somewhere; use Google if you need it.

In case you meant the other kind of source (kind of rude)
to prove that Windows is using the NAND, I'll just have to
say that Mitch said so on IRC. It's also just plain silly to
think that Windows wouldn't use the NAND, both because
it is a valuable resource and to block competition.

Post by Edward Cherlin
Who says what the dual-boot architecture will be? If
you won't be able to run Linux after the first time you run Windows,
as you seem to allege,

I don't know where you got that idea. Plain old Linux
will boot from a USB stick, but it won't be shipping
with the laptop. Since the NAND is in use by Windows,
there won't be a Linux to begin with.

Post by Edward Cherlin
in what sense is this dual-booting? Are Mitch
and Scott such technical idiots that they wouldn't spot this?

Right, it's not dual-booting. Dual-booting won't ship,
at least in large deployments.

Post by Edward Cherlin

Post by Albert Cahalan

Also, I think you completely misunderstand the market. The ability to
use Open FirmWare instead of a proprietary BIOS will be of intense
interest to all PC vendors. I expect OFW to sweep through most of the
market in no more than two or three years.

I can't imagine why. LinuxBIOS (now coreboot) didn't.
Even EFI didn't. Your wishes are not their wishes.

Albert, I'm not talking to you any more until you start making sense.
Linux BIOS never booted any Windows other than 2000 (with ADLO), and
EFI isn't Open Source.

You think the PC vendors care that EFI isn't Open Source?
You think the PC vendors care that BIOS isn't Open Source?
Really, they have NO desire for Open Source firmware.

That's your desire, not theirs. Do not assume they think like you.

[Carl-Daniel Hailfinger]

Post by Albert Cahalan

Post by Edward Cherlin

Post by Albert Cahalan

Also, I think you completely misunderstand the market. The ability to
use Open FirmWare instead of a proprietary BIOS will be of intense
interest to all PC vendors. I expect OFW to sweep through most of the
market in no more than two or three years.

I can't imagine why. LinuxBIOS (now coreboot) didn't.
Even EFI didn't. Your wishes are not their wishes.

Albert, I'm not talking to you any more until you start making sense.
Linux BIOS never booted any Windows other than 2000 (with ADLO), and

That's not really true. coreboot (former LinuxBIOS) does boot XP and
Vista with the right payload. I should know it, I'm one of the coreboot
developers. Granted, that knowledge is not spread far and wide.

Post by Albert Cahalan

Post by Edward Cherlin
EFI isn't Open Source.

That's not entirely accurate. There are EFI implementations which are
Open Source, but EFI is just a presentation layer and performs no
hardware init, so you're back to square one.

Post by Albert Cahalan
You think the PC vendors care that EFI isn't Open Source?
You think the PC vendors care that BIOS isn't Open Source?
Really, they have NO desire for Open Source firmware.

Indeed. Some companies say that any public code for hardware init poses
a threat to their intellectual property and/or is baaad for various
made-up reasons.

Post by Albert Cahalan
That's your desire, not theirs. Do not assume they think like you.

I can tell you how many hardware vendors think:
- Does it reduce cost? If not, scratch the idea.
- Does it make the lawyers nervous? If yes, scratch the idea. In
general, lawyers of hardware vendors get nervous once somebody suggests
to publish anything, regardless whether the content is obvious or not.
- Is it still compatible with DOS and any and all legacy operating
systems ever invented (including Windows 95/98/ME)? If not, scratch the
idea unless your intended market (high-end gaming rigs or somesuch) will
never want that compatibility. This is evident from the mainboards you
can actually buy with EFI.


Regards,
Carl-Daniel