[OLPC Security] How much of architecture document is actually implemented
mleech at nortel.com
Wed Oct 10 15:40:05 EDT 2007
Michael Stone wrote:
> Thanks for your interest. Hopefully this overview will give you enough
> information to figure out where to further direct your attention and
> Today, the relevant players in this area are:
> Ivan Krstić -> security architect, hardware cryptography,
> server-side anti-theft & activation infrastructure
> C. Scott Ananian -> activation initramfs & client-side anti-theft; os
> update verification
> Mitch Bradley -> firmware
> Michael Stone -> containerization
> The relevant git repositories, published on dev.laptop.org, are
> olpcrd-rootskel <- initramfs
> users/cscott/leases <- lease-checking code
> users/cscott/rmanifest-py <- os manifest creation/verification
> users/mstone/security <- containerization prototype ("rainbow")
> bios-crypto <- lease & developer key construction tools
> The overall summary is that we are confident that, for FRS (i.e. the
> software release to be installed during deployment), we can deliver the
> client-side component of first-boot activation and little else.
> The server-side, manufacturing-side, and deployment-side software for
> first-boot activation are still large unknowns.
> We have a functional research prototype for activity containerization
> that we are presently integrating in to the existing images; however,
> it's shippability is uncertain.
> We have spent essentially no time on user-land and kernel-level
> hardening or on data-collection software for "soft" security.
> Does this synopsis address your initial question?
Michael, thanks very much for the synopsis.
It sounds like there's still an awful lot to do to realize the vision
contained in the BitFrost security document.
My management here at Nortel has volunteered roughly half of my time to
work on XO security "stuff", so I want to
get as much good material as I can about what already exists, and how
it all fits together. I'm probably going to have
to go through the mailing-list archives to try and get up to speed.
The piece of the architecture that allows software to be "installed"
with specific permissions very much reminds me of
VMS--which had a plethora of permissions that software could be
installed with for it to gain various access rights
and privileges. But in the end, the very-fine-grained permission
structure didn't work out that well. In terms of
protecting against malicious software, many of the granted permissions
would allow a process to "hill climb" up
to higher effective permission levels, through various subterfuges.
Thanks again for the info.
Security Standards Advisor
Nortel CTO Office
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.laptop.org/pipermail/security/attachments/20071010/83737f04/attachment.pgp
More information about the Security