[OLPC Security] G1G1: Security, to enable or disable...

[ffm]

Why were G1G1 machines shipped with firmware, kernel, and reflash locks
enabled? (see http://wiki.laptop.org/go/Developer_keys )

Theft is not a good reason, as they do not require activation leases.

It only seems to be a bother for people who want to help out with the OLPC
project.

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

[C. Scott Ananian]

Post by ffm
Why were G1G1 machines shipped with firmware, kernel, and reflash locks
enabled? (see http://wiki.laptop.org/go/Developer_keys )
Theft is not a good reason, as they do not require activation leases.
It only seems to be a bother for people who want to help out with the OLPC
project.

The original reason is that it allowed our G1G1 users to more fully
exercise/test our secure boot paths, which are used in our deployment
countries. This helps G1G1 users be more representative testers, and
did successfully flush out security logistics issues like the ones you
seem to be complaining about before they became a big issue for
deployment countries.

A secondary consideration was that secure boot is tied to "pretty
boot", since we assume that if you are a developer you won't be scared
of boot messages. A non-tech-team charge was to ensure that G1G1
machines looked pretty while booting. This seems trivial to us, but
was in fact a big concern for non-developers involved in the program.

These issues can probably be revisited before a second G1G1 program,
but my personal feeling is that we eventually do have to make the
antitheft security stuff "just work" and not get in ordinary people's
way (if you're a developer, you should be able to acquire a developer
key easily and you should do so). Having G1G1 use a subset of these
features allows more extensive testing and thus helps us produce
better software for deployment countries. So, contrary to your
statement that "it only seems to be a bother for people who want to
help out with the OLPC project", having security enabled is one of the
direct ways that people who want to help out *are in fact already
doing so*. [And complaining about security when it gets in your way,
within reason, is also directly helping out. =) ]

G1G1 has always had slightly mixed goals, because N% of the people
buying G1G1 machines are developers, and ~(100-N)% are parents or
grandparents of small children. I believe N is well below 50%, based
on devel@ traffic. Machines sent out via our developer program are
always shipped out unsecured. We assume that G1G1 developers have the
ability to request a developer key and disable security, and we
recommend they do so; the security features are not meant for them.
--scott

[ffm]

Machines sent out via our developer program are always shipped out
unsecured.

Yet I've just recived two laptops via said program that had security
enabled.

-FFM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080603/32e765ee/attachment.htm

[Bert Freudenberg]

On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian

Machines sent out via our developer program are always shipped out
unsecured.

Yet I've just recived two laptops via said program that had security
enabled.

Indeed. The machines distributed at LinuxTag last week also came w/o
dev key - I think it is only the activation part that is disabled.

- Bert -

[C. Scott Ananian]

Post by Bert Freudenberg

On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian

Machines sent out via our developer program are always shipped out
unsecured.

Yet I've just recived two laptops via said program that had security
enabled.

Indeed. The machines distributed at LinuxTag last week also came w/o
dev key - I think it is only the activation part that is disabled.

My information may be out of date on the developer's program, since
Adam has rebooted it recently and I don't think that developer's
program machines actually come through OLPC any more. I should have
said, "used to be shipped out unsecured". Adam, are the new
developer's program machines shipped direct, or do we have an
opportunity to (at least) include a flyer explaining how to disable
security on the machine?
--scott

[Kim Quirk]

Developer program laptops are shipped out as US/International
keyboards, English language, AK flag set, which means they do NOT need
activation. They are permanently activated in the manufacturing data.

The only thing they need to be a developer unit is a developer key.

One more reason to add to Scott's list of why laptops are sent out to
G1G1 'write protected' is so they are protected from non-signed images
coming from malicious sources. If you don't use a developer's key to
un protect the laptop, then you can only upgrade to OLPC signed
builds. This is an important part of the bitfrost security that is
implemented and working!

FFM - if you really got two laptops from the developer's program that
weren't activated, then could you put those details into an RT ticket
and we'll debug it there. If there really are laptops going out that
are un-activated that we don't know about, that will be a serious
problem.

The ONLY un-activated laptops are ones built for Peru, Mexico, and
Uruguay. These are very specific SKUs and that include Spanish
keyboards. Please open a ticket and let's figure that out.

Thanks,
Kim

Post by C. Scott Ananian

Post by Bert Freudenberg

On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian

Machines sent out via our developer program are always shipped out
unsecured.

Yet I've just recived two laptops via said program that had security
enabled.

Indeed. The machines distributed at LinuxTag last week also came w/o
dev key - I think it is only the activation part that is disabled.

My information may be out of date on the developer's program, since
Adam has rebooted it recently and I don't think that developer's
program machines actually come through OLPC any more. I should have
said, "used to be shipped out unsecured". Adam, are the new
developer's program machines shipped direct, or do we have an
opportunity to (at least) include a flyer explaining how to disable
security on the machine?
--scott
--
( http://cscott.net/ )
_______________________________________________
Devel mailing list
Devel at lists.laptop.org
http://lists.laptop.org/listinfo/devel

[Samuel Klein]

I continue to be uncomfortable that we are sending out restricted /
locked-down machines without a clear need. The arguments made so far for
this are

1. "Getting G1G1 people to test security steps"
2. "Protecting G1G1 donors from installing anything but signed builds"
3. "Showing a pretty boot screen"

3. represents a bug that should be fixed. Tying pretty boot to
machine-lockdown is arbitrary.

2. assumes that this is the best result for G1G1 donors, which seems
unlikely to me. Discovering how to update to anything but the most
aggressively promoted builds is already a sign of tech savvy. This
protection would still effectively be in place for the vast majority of
users for whom it matters if we aggressively recommended to users (say,
after a couple of days of use) that they get a developers key if they want
full control of their machines for any reason.

1. is an interesting argument. As with 2, it would still hold if recipients
were actively encouraged to get developers keys if they have any interest in
having full control of their machines (indeed you could say that they we
would have a much better test of the dev-key acquisition process, which
currently works more clearly in large batches for countries than for
individuals).

SJ

Post by Kim Quirk
Developer program laptops are shipped out as US/International
keyboards, English language, AK flag set, which means they do NOT need
activation. They are permanently activated in the manufacturing data.
The only thing they need to be a developer unit is a developer key.
One more reason to add to Scott's list of why laptops are sent out to
G1G1 'write protected' is so they are protected from non-signed images
coming from malicious sources. If you don't use a developer's key to
un protect the laptop, then you can only upgrade to OLPC signed
builds. This is an important part of the bitfrost security that is
implemented and working!
FFM - if you really got two laptops from the developer's program that
weren't activated, then could you put those details into an RT ticket
and we'll debug it there. If there really are laptops going out that
are un-activated that we don't know about, that will be a serious
problem.
The ONLY un-activated laptops are ones built for Peru, Mexico, and
Uruguay. These are very specific SKUs and that include Spanish
keyboards. Please open a ticket and let's figure that out.
Thanks,
Kim

On Tue, Jun 3, 2008 at 12:43 PM, Bert Freudenberg <bert at freudenbergs.de>

Post by Bert Freudenberg

On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian

Machines sent out via our developer program are always shipped out
unsecured.

Yet I've just recived two laptops via said program that had security
enabled.

Indeed. The machines distributed at LinuxTag last week also came w/o
dev key - I think it is only the activation part that is disabled.

My information may be out of date on the developer's program, since
Adam has rebooted it recently and I don't think that developer's
program machines actually come through OLPC any more. I should have
said, "used to be shipped out unsecured". Adam, are the new
developer's program machines shipped direct, or do we have an
opportunity to (at least) include a flyer explaining how to disable
security on the machine?
--scott
--
( http://cscott.net/ )
_______________________________________________
Devel mailing list
Devel at lists.laptop.org
http://lists.laptop.org/listinfo/devel

_______________________________________________
Devel mailing list
Devel at lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Michael Stone]

Shipping G1G1 machines with NAND reflash locks enabled makes little
sense to me. What good is protection against malicious reflash when any
attacker who can perform a reflash has physical access to the device and
has password-free root access in default configurations?

Instead, the justification that I recall most strongly from when I last
inquired about the purpose of enabling the NAND reflash lock on G1G1
machines is that it is primarily intended to reduce support costs by
making it harder to test non-Released builds via reflash. I countered
that the value of the extra testing we might receive would far outweigh
the extra support costs that we might incur but, evidently, my argument
was not decisive.

Scott - were there other justifications given for the NAND reflash lock?
I vaguely recall that you argued that, by default, OFW ought to be
prohibited from writing unsigned data to the NAND on the grounds that
bugs in the prohibited code paths might otherwise violate security goals
of clients shipping passive-kill or active-kill technologies. Did I
recall your justification correctly?

Michael

[C. Scott Ananian]

Post by Michael Stone
Scott - were there other justifications given for the NAND reflash lock?
I vaguely recall that you argued that, by default, OFW ought to be
prohibited from writing unsigned data to the NAND on the grounds that
bugs in the prohibited code paths might otherwise violate security goals
of clients shipping passive-kill or active-kill technologies. Did I
recall your justification correctly?

I'm confused, Michael. I outlined the reasons above for shipping the
machines with security enabled. But you seem to be talking about
reflash capability, which is strange. No one seems to be arguing that
G1G1 machines want to be using copy-nand except you -- and maybe Kim?

Briefly restating my opinion:

1) I find the additional testing of the secure code path and the
developer key request mechanism achieve by shipping G1G1 with
activation but not developer keys extremely useful. But then, I'm the
primary developer/maintainer of these systems, so I feel more strongly
the necessity of making them work.

2) I feel that developers program machines (as opposed to G1G1
machines) should probably be shipping out with security disabled, or
with instruction on how to get a developer key, so that developers
don't have to jump an unnecessary "how do I upgrade to a development
build" hurdle. But this can probably be accomplished by sending
developers program folks an email when we approve their request.

3) Once security is enabled on the machine, our current security
architecture requires that we will need to restrict writes to NAND in
order to protect the root account. I'm not going to revisit this
debate now, because it's off-topic and dependent on our security work
with Uruguay next week, etc, etc. This thread is about #1, which we
did for G1G1v1 and I would support for G1G1v2, and #2, which we did in
the past but apparently have not been doing recently. Let's start a
different thread (preferably post-Uruguay's visit) if we want to
reopen #3.
--scott

[C. Scott Ananian]

Post by Samuel Klein
I continue to be uncomfortable that we are sending out restricted /
locked-down machines without a clear need. The arguments made so far for
this are
1. "Getting G1G1 people to test security steps"
2. "Protecting G1G1 donors from installing anything but signed builds"
3. "Showing a pretty boot screen"
3. represents a bug that should be fixed. Tying pretty boot to
machine-lockdown is arbitrary.

agreed. as a G1G1 owner i wanted to see the boot messages quite
a long time before i needed or wanted a dev key.

http://wiki.laptop.org/go/Cheat_codes

the 'check' key is what you are looking for.

Post by Samuel Klein
1. is an interesting argument. As with 2, it would still
hold if recipients were actively encouraged to get developers
keys if they have any interest in having full control of their
machines (indeed you could say that they we would have a much
better test of the dev-key acquisition process, which
currently works more clearly in large batches for countries
than for individuals).

i would have thought G1G1 proved that dev-key acquisition works
just fine.

That's my hope. Shipping G1G1 with security enabled forced us to
properly prioritize bugs with dev key request/fulfillment, and to
build tools to make requesting a dev key easy. That was a success,
from my perspective.

I'd like to be able to offer the same antitheft protection we will be
trying to offer Uruguay to G1G1 users as well, on a voluntary basis,
and roughly the same reasoning. If something goes wrong or it doesn't
work like it should, G1G1 users are communicative and English-literate
canaries in the coal mine. And diagnosing and fixing the problem is
much easier for G1G1 than it is for some small village in Uruguay a
week's walk from anything.

But again, my perspective is warped by having to write this code and
be confident in its correctness. I want as much help as I can get.
--scott

[reynt0]

On Tue, 3 Jun 2008, C. Scott Ananian wrote:
. . .

Post by C. Scott Ananian
The original reason is that it allowed our G1G1 users to more fully
exercise/test our secure boot paths, which are used in our deployment
countries. This helps G1G1 users be more representative testers, and

. . .

I'm a G2G2. Among my interests was to experience as much
as possible *exactly* what a deployment-country child would
be experiencing when opening an XO for the first time
(anticipation, mystery, caution about breaking something
in limited supply and special, ...?). If I had any idea
while I was opening it about running it like an expert,
that wouldn't be the experience. So I was happy about the
security state. Computing--and the computing use experience
OLPC is sharing around the world--involves a lot more than
hardware and software, IMO.

I also want to be able to examine the XO as thoroughly as
possible from my own (USA, educated, experienced, and so
on) perspective. In that regard, FWIW I found the various
infos I later could find from olpc a bit unclear or even
seeming at first glance inconsistent about how usable a
G1G1 XO could be as-delivered. My present understanding
is that I will need a developer's key, and that I can get
one by asking when I'm ready to (though I'm not sure if
I would be able to if I were a non-compsci G1G1), tho I
am willing to accept that this understanding may be wrong.

(FWIW, I'm on this thread only via the security list.)

[C. Scott Ananian]

Post by reynt0
I also want to be able to examine the XO as thoroughly as
possible from my own (USA, educated, experienced, and so
on) perspective. In that regard, FWIW I found the various
infos I later could find from olpc a bit unclear or even
seeming at first glance inconsistent about how usable a
G1G1 XO could be as-delivered. My present understanding
is that I will need a developer's key, and that I can get
one by asking when I'm ready to (though I'm not sure if
I would be able to if I were a non-compsci G1G1), tho I
am willing to accept that this understanding may be wrong.

http://wiki.laptop.org/go/Developer_key

I would like to see the link for requesting a developer key made much
more prominent in the library. (I've cc'ed SJ specifically to see if
he can make that happen for me.)
--scott

[Kim Quirk]

The two issues that I am concerned about regarding the write protect
flag with regards to G1G1:

1 - I thought requiring signed images was part of our bitfrost
security. Doesn't it provide some protection from malicious images?
Assuming we get to the point where upgrading is an easy click from the
G1G1 machine, then we want to be sure that people don't mistakenly
load non-signed images. If you are not a developer; doesn't this add a
level of protection that we want for 90% of G1G1 recipients?

2 - I believe our support issues will go up significantly as people
who have little or no experience are encouraged to download all sorts
of untested builds with no easy way to get back to a working system.
To feel better about the support issues, I would like the one-button
push that restores a laptop to factory default. Actually walking
people through a cleaninstall is a very time-consuming process right
now.

Finally, I agree with Scott, that the easiest thing we can do in the
short term is to make the 'get a developer key' more prominent for
those who want to find it. I would really like a brief note about how
they should first be familiar with how to do a factory cleaninstall
before they unprotect their machine.

Kim

Post by ffm

Post by reynt0
I also want to be able to examine the XO as thoroughly as
possible from my own (USA, educated, experienced, and so
on) perspective. In that regard, FWIW I found the various
infos I later could find from olpc a bit unclear or even
seeming at first glance inconsistent about how usable a
G1G1 XO could be as-delivered. My present understanding
is that I will need a developer's key, and that I can get
one by asking when I'm ready to (though I'm not sure if
I would be able to if I were a non-compsci G1G1), tho I
am willing to accept that this understanding may be wrong.

http://wiki.laptop.org/go/Developer_key
I would like to see the link for requesting a developer key made much
more prominent in the library. (I've cc'ed SJ specifically to see if
he can make that happen for me.)
--scott
--
( http://cscott.net/ )
_______________________________________________
Devel mailing list
Devel at lists.laptop.org
http://lists.laptop.org/listinfo/devel

[Frank Ch. Eigler]

[...] Finally, I agree with Scott, that the easiest thing we can do
in the short term is to make the 'get a developer key' more
prominent for those who want to find it. [...]

Taking away the 24 hour delay between key request and response could
help solve both problems.

- FChE