Re: Installing RPMS via Customization Key

2008-03-07 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Stone wrote:
| It's completely unsafe to use the new USB customization keys to execute
| software located on-key or on-NAND because any opportunity for arbitrary
code
| execution as uid 0 represents a serious threat to our first-boot activation
| security.
|
| Since we appear to want to be able to customize images with new RPMS, this
| leaves us in a somewhat sticky situation. The following patch represents one
| approach to resolving the difficulty - that of postponing the running of any
| commands until after the activation initramfs yields control to late
userland.

It is difficult to comment on this without more detail on USB
customization keys.  My understanding was that such customization would
be done once at the level of whole countries, that it would be restricted
to /home, and that the key in question was a cryptographic signing key,
so that customizers (at the ministry of education) could create trusted
images that the firmware or journal would install automatically.  Thus, I
am not sure what a USB customization key is.

Countries that want to make invasive modifications to the operating system
should be allowed to do whatever they want, but allowing users to add
arbitrary RPMs without a developer key is a distinctly terrible idea.  I
cannot tell which you are proposing here.

Your patch does not suggest that the set of RPMs is signed.  Is there a
signature validation happening somewhere?

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH0VMMUJT6e6HFtqQRAvPJAJ9DQZoRGeoux2p2jLppPOku/QPBfACfcHgY
UePE4MqAOjpzj5Ykr4I8uIM=
=S8uD
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Installing RPMS via Customization Key

2008-03-07 Thread C. Scott Ananian
On Fri, Mar 7, 2008 at 9:37 AM, Benjamin M. Schwartz
[EMAIL PROTECTED] wrote:
  It is difficult to comment on this without more detail on USB
  customization keys.  My understanding was that such customization would
  be done once at the level of whole countries, that it would be restricted
  to /home, and that the key in question was a cryptographic signing key,
  so that customizers (at the ministry of education) could create trusted
  images that the firmware or journal would install automatically.  Thus, I
  am not sure what a USB customization key is.

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

It is specifically design to allow countries (or schools) to create
customied builds *without* requiring OLPC to sign or approve their
changes.  In exchange, we require the modifications to be restricted
to /home so that we've got some hope of successfully diagnosing or
updating their builds.  I will refuse to sign any build with this
patch in it, and I don't feel that Michael has made any case for why
it is necessary.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Installing RPMS via Customization Key

2008-03-07 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

C. Scott Ananian wrote:
| On Fri, Mar 7, 2008 at 9:37 AM, Benjamin M. Schwartz
| [EMAIL PROTECTED] wrote:
|  It is difficult to comment on this without more detail on USB
|  customization keys.  My understanding was that such customization would
|  be done once at the level of whole countries, that it would be restricted
|  to /home, and that the key in question was a cryptographic signing key,
|  so that customizers (at the ministry of education) could create trusted
|  images that the firmware or journal would install automatically.  Thus, I
|  am not sure what a USB customization key is.
|
| http://wiki.laptop.org/go/Customization_key
|
| It is specifically design to allow countries (or schools) to create
| customied builds *without* requiring OLPC to sign or approve their
| changes.

Right.  I thought the solution was that each country was to be given its
own customization signing key that allowed them to construct modified
images and sign them without OLPC approval.  Only signed customizations
would be installed automatically.  This would solve the problem of
privilege escalation.  I guess I misinterpreted the word key.

| In exchange, we require the modifications to be restricted
| to /home so that we've got some hope of successfully diagnosing or
| updating their builds.  I will refuse to sign any build with this
| patch in it, and I don't feel that Michael has made any case for why
| it is necessary.
|  --scott
|

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH0V+nUJT6e6HFtqQRAmd1AJ0bTWKkqdkpe2eHJYWrbmd/ukb8uQCfRf/v
mC7ZoOrZ/VMGyRtG/65z51k=
=pdHe
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Installing RPMS via Customization Key

2008-03-07 Thread C. Scott Ananian
On Fri, Mar 7, 2008 at 10:30 AM, Benjamin M. Schwartz
[EMAIL PROTECTED] wrote:
  | It is specifically design to allow countries (or schools) to create
  | customied builds *without* requiring OLPC to sign or approve their
  | changes.

  Right.  I thought the solution was that each country was to be given its
  own customization signing key that allowed them to construct modified
  images and sign them without OLPC approval.  Only signed customizations

The signed part of the customization key is universal.  IMO we can't
afford to intervene in every deployment.
  --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Installing RPMS via Customization Key

2008-03-06 Thread Michael Stone
Friends,

It's completely unsafe to use the new USB customization keys to execute
software located on-key or on-NAND because any opportunity for arbitrary code
execution as uid 0 represents a serious threat to our first-boot activation
security.

Since we appear to want to be able to customize images with new RPMS, this
leaves us in a somewhat sticky situation. The following patch represents one
approach to resolving the difficulty - that of postponing the running of any
commands until after the activation initramfs yields control to late userland.

Let me know what you think, both of the patch and of the approach,

Michael


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel