Talk:Bitfrost

Correlating Bitfrost and Threats

A new page, Correlating Bitfrost and Threats, has been added that correlates the Bitfrost spec with the Threats and Mitigation page, which was published prior to publication of the spec.

Typos

1. I can't edit the page, but the link to spec on git is broken I the night one is http://dev.laptop.org/git?p=security;a=blob;f=bitfrost.txt

   Fixed — I think that after dev.laptop.org got updated, the /git.do? got changed to /git?. --Xavi 23:11, 12 September 2007 (EDT)

2. I can't edit the page, but the "No permanent data loss" box has a typo: in the event that

   Fixed

He / She / S/He

Discussion has been moved to Gender and OLPC.

Unix permissions

The author describes some version of typical Unix permissions and security model behind it and then complains that with this model "we can't stop viruses and malware" and that "anyone can send a user an executable program, and for many years the users' instinctive reaction was to open the attachment and run the program." The reality is quite different really. I use Unix systems since 15+ years. My machines were never eaten by a virus and I never have run a program directly from an attachment. The only problem with e-mail viruses is that they add to spam but it is very easy to filter viruses anyway.

If you start your design of new security model with such false assumptions your results may be still right at the end - or may be not.

I'm not the author, but I think the new security model is a pretty good idea. Sure, you or I may not have gotten viruses, but nearly every inexperienced computer user I know has gotten one. You are lucky that you know not to open attachments and that Unix is not a high target for virus writers -- because there are not many Unix machines, and most of their owners know better than to open attachments or run strange programs. But the OLPC changes this: it will bring online a huge population of inexperienced computer users. It will be a magnet for botnets and mischief-makers. It deserves a well-thought-out security system.

The benefit of the Unix permission system is that a user can only screw up their own files, not the files of other users or the operating system itself. As beneficial as this is, it is hardly a consolation to the user who has just lost all their files because they ran a program a "friend" sent them. Your solution is to advise the user never to run programs from other people, but this approach simply does not work, as we have seen with Windows. And, besides, one of the goals of OLPC is to allow its users to make new programs and share them with each other.

It sounds like the Bitfrost approach is to create a file system sandbox for each application so that it can't interfere with other applications. This seems entirely reasonable to me. After all, it's what Java, .NET, and Flash do to allow the user to run unsafe applets. Python, the main OLPC development system, doesn't have this kind of sandbox (yet), so it's a good thing if the underlying operating system can provide it. —Leejc 19:49, 7 February 2007 (EST)

One Brick per child?

"The sole purpose of these keys will be to verify the integrity of bundled software and content" - what is five years down the line, the child has got bored of Squeak etc and decides to install a different Linux distro, will the DRM brick the laptop?

Should not be a problem. The brick function looks like it is part of the XO's Linux operating system. If you replace the OS you remove the brick function. Note that you would need a developers key to replace the OS. -- tef 14:30, 8 February 2007 (EST)

Legitimizing "Big Brother" and DRM

We all know that DRM is the enemy of open source projects, and is in fact tagged with "Defective by design". Why are you taking away the kid's control over their laptop on SECURITY concerns. You should know by now, if hackers want to use it, they will. Remember windows genuine advantage? Hackers cracked it too. All it did was hurt the end user.

I implore you (laptop.org) not to make the same mistake that Microsoft did. As much as I am hyped about your creation, I cannot help but feel dread as this proposed "security" idea steals control from the child, who is learning about computers through interacting with it, and giving it to an arbitrary authority who may misuse their power at any time. - Teenage system admin for Los Gatos Highschool.

We all know what now? I thought the enemy of Open Source was Closed Source. DRM is not mentioned in the article, it also does not have to be closed source

Did you actually read the security specification? Nowhere does it discuss taking kid's control away, or DRM systems. --Jacobolus 12:19, 9 February 2007 (EST)

The theft protection servers activated by some countries means that a government administration could actually lock the machines off (theoretically if a machine was reported stolen, but also theoretically if an administration decided the machines were being used by an insurgency). That's part of the bitfrost security specification. It could be considered sort of DRMish. Given the complex issues facing the project, I don't think it's so bad. --Jeff 8:20, 16 Feb 2007 (EST)

What about a case where (due to financial, government policy , etc.) reasons, a government ends their OLPC project and shuts down authentication services (the server as well as the USB dongle distribution system) - is there a way to centrally bless all the laptops to continue working or give them a functionally infinite lease (provided that they can re-authenticate before the shutdown)? I'm reminded of Circuit City's problem with the DIVX pay-per-use DVD disks (news.com.com) -- Griffjon 12:28, 22 February 2007 (EST)

Should easily be handled by the same procedures as when the country's central XO organization sends out a USB-stick to the schools to extend the lease (if the school's internet access is down, if not just send the keys out over the internet). Wouldn't be hard to set the lease time to "forever". -- OskarLissheim-Boethius 21:52, 3 March 2007 (CET)

centralized storage

" Information on the laptop will be replicated to some centralized storage" OLPC is targeted at not so rich kids, do they all have internet access or are authors going to give blank cd/dvd and some stamps to send all those data from laptop to "some centralized storage"?

You don't need internet access to reach the school server, the wireless mesh will do just fine. And if that is not available (distances, obstacles, etc) you can see Motoman or UUCP for alternatives and Internet for the general outlook.

BTW, you would also need to ship some USB CD/DVD burners with the laptops... not just the stamps and blank media... --Xavi 13:52, 8 February 2007 (EST)

Open design

"The laptop's security must not depend upon a secret design implemented in hardware or software." Well, like Theo de Raadt pointed out in an open letter, the documentation of the Marvell chip is not publicly available. This is in contradiction to "must not depend on a secret design implemented in hardware and software". What is more secret? Documentation that's just available or documentation that's available under NDAs? For anyone interested, this is a link to Theo's mail archive about this issue: http://www.theos.com/deraadt/jg

If you want to argue about open design, do it on one of the hardware discussion pages. --69.136.111.100 14:11, 16 February 2007 (EST)

security that doesn't depend on passwords

the only simple secure option is voice authentication. someone from OLPC contact me - lkcl@lkcl.net - for details: i have a friend who has implemented a secure voice-authentication system. that actually works. it's being used in banks. 99.5% reliable. 100% accurate.

Across hundreds of languages, and adolescent boys? Homunq 19:22, 1 August 2007 (EDT)

Security Should be Right-Sized!!!

Assume officals are self serving, and governments will use any central repository to coerce the users. Because of this, activiation, theft protection and user control must be fully decentrallized at the 'school level'.

There can be no means for a government or in-country master key holder to exert control. This control, for example, could simply be threats of shutting down the OLPC population used by an ethnic group unless a that group submits to a demand, such as placing one of its leaders into government custody.

I think the complexity of the BitFrost security model is a bit heavy

Lets not apply western complexity appropriate for western security risks and sensitivities to what obstensibly is a small child's educational tool. There is no sensitive data of consequence, and once denied the mesh, terrorists or other kids won't want it. The V-tech 'laptops' found at Walmart don't have much of a security model, yet it's model is adequate to the social needs.

Personally, I think that it's a ver interesting setup of things that manages to address many of the modern issues in a 'networked' community... I don't think it's perfect, but it really tries to address the current issues, not the legacy ones (that have been proven to fail and are constantly trying to hack a solution or catch up with new threats). --Xavi 12:24, 10 March 2007 (EST)

yes, BitFrost is a thing of beauty, but can someone tell me why each of its components are specifically needed in the intended context?

See the spec... OLPC Bitfrost or more specifically OLPC Bitfrost#Addressing the threat model

BTW, please sign your entries.

My 'answers' are just my point of view... they should NOT be taken as anything official! :) --Xavi 01:05, 12 March 2007 (EDT)

Why does the user even have to identify himself to the computer?

Windows95 was good enough and demanded no login.

Windows95 has no security, and many would consider it a security threat in itself.--Xavi 12:24, 10 March 2007 (EST)

Okay, if a user did something bad, then we'd know which 8 year old to blame. Please do keep in mind that these are KIDS so why is accountability so important??? Win95 was functional for kids. However when we had CIA files to protect, it became less effective. When we released a virus to the world, there was no throat ot choke, since nobody knew which logged in user dispatched it. Is accountability important in order to protect the internet - Not; to protect the other 8 year olds in the same mesh? Will the laptop ever support multiple logins - probably not. Presence services on the laptop do not need a positive identification, since you don't log into a cellular phone before participating in the same 'presence' community.

Are we concerned that an adult superhacker will zombify all the laptops? If he wanted to, I'm sure he could trick the 8yr old owner enough to get exclusive use of his laptop for enough time. I think a 'please' and a candybar might suffice!

Can someone please specifically enumerate the security threats to a group of 8 year olds using these laptops in the expected way, that justifies the need for login control? I don't think chellenging the common wisdom should automatically be dismissed out of hand.

Login management (afaik) is not an issue. Maybe you are referring to the concept of 'digital identity' instead generated at first boot? I could be wrong, but as I read the spec, never again will the child need to identify himself again, the laptop becomes the identity... no passwords to remember nor anything, while allowing the buddies, friends, and other people distinctions in the mesh.

Yes, that (superhacker) is a risk, but because there's some sort of 'throttle' on the propagation speed for unsigned code together with mutually exclusive rights, the superhacker will probably have trouble zombifying a big population...--Xavi 01:05, 12 March 2007 (EDT)

Why is theft protection so important?

This assumes that unknown machines can't participate in any school mesh, so they becomes quite useless. If the machine reappears on the original mesh where it was lost, the administrator could disable it, until its user is identified.

Theft-protection is 'important' in the sense that it's a very big unknown. Ignoring the promises and doubts about the educational aspects of the project itself; nobody really knows how effective will the laptops be in staying within the educational context. And from previous experiences where some 'public' things end up in 'private' hands, it makes sense for countries (and other people) to worry about the issue.

After all, if you pay USD 135,000,000 but at the end of the year instead of the million laptops you end up with just 200,000 laptops inside the education system, the price / laptop turned out to be USD 675... not a nice outcome; but from the public official's responsibility and the spending of public money (or worse, loaned money and public debt) it is a major issue.--Xavi 12:24, 10 March 2007 (EST)

yes, I can accept that, however this protection does not require individual login management, it just need hardware identification (MAC address-based maybe)

MAC is not bulletproof, it can be spoofed (both for valid and not so valid reasons). And the anti-theft works based on the Serial Number + UUID of the laptop (generated at the factory plant), not the child's 'digital identity'. --Xavi 01:05, 12 March 2007 (EDT)

Tux Paint requirements

First, FYI, Tux Paint is a paint program with extreme ease of use. A few 2-year-olds and many 3-year-olds are able to manage it well. Tux Paint uses stereo sound controlled by where the user is drawing. Tux Paint is localized into about 40 different languages including big-alphabet and right-to-left ones.

Tux Paint needs to get at the raw font files. It scans /usr/share/fonts and other common locations for TrueType, OpenType, and Postscript fonts. It then test-renders the fonts in a background task so that it can put good fonts (good for the current locale) at the top of the list.

Tux Paint expects to print. It is normally set up to send Postscript via lpr. It would be easy to send a PPM or PNG, and easy to use something other than lpr.

Tux Paint keeps all images private. They are of fixed size. (no zoom, no scroll bars, no resizable window, no wasted screen space) There is a built-in file dialog that uses thumbnails to select images. There is no way for the user to navigate out of the image directory. Normally the image directory is hidden from the regular GUI desktop. (be that GNOME, KDE, MacOS X, Windows, OS/2, BeOS, or PDA) Images may have associated meta-data files. Importing and exporting images might be nice, but would complicate the UI, so probably there is no need to worry about this issue. Tux Paint allows images to be deleted.

Tux Paint is normally not fully self-contained, for good reason. Tux Paint itself comes in at about 5 MB. (not counting any missing libraries like SDL) There is also a 20 MB clip-art collection, often called "tuxpaint-stamps". The clip-art is special purpose and not normally edited by users; a regular image collection will not work. If there is no way for Tux Paint to get at the stamps, then Tux Paint becomes 25 MB or loses this fairly critical feature.

AlbertCahalan 00:48, 10 March 2007 (EST)

Link to 'complete Bitfrost specification'

It would be good to add an URL to the phrase: "complete Bitfrost specification" at the end of the page. Norm Hardy

I concur. I was also considering doing this. Does anyone object? -Ericsilva 17:53, 27 November 2007 (EST)

Activation process and preventing grey marketing of the Laptop

I have a couple of questions concerning the laptop's activation process.

First of all, is the "unlocking" part of the activation process (which takes place upon the laptop's first boot) handled by the Laptop's firmware/BIOS? Or is it done via the OS?

Also, in what way is the user prevented from flashing a BIOS that circumvents this authorization process and puts the laptop in a permanently activated state? I believe that such a thing would not be too hard to achieve considering that both the BIOS (and i suppose the firmware) of the Laptop are open source.

Finally, is there some way to prevent the flashing of the BIOS via an external flasher? Or even the usage of an alternative BIOS chip (in the way modchips are used to circumvent copy protection methods in consoles)?

Thanks in advance for the answers :) --Shodanjr gr 22:46, 18 March 2007 (EDT)

What is the "one question"?

there is only one protection provided by the Bitfrost platform that requires user response, and even then, it's a simple 'yes or no' question...

But nowhere is it explained which protection that is. --Alexander Dupuy 72.231.167.9 14:40, 4 September 2007 (EDT)

off the top of my head, the 'one question' I remember being asked by the system is the one about authorizing a program's use of the microphone and/or camera. It's mentioned in the OLPC Bitfrost (not Bitfrost) section on the microphone & camera protection, iirc. Xavi 23:23, 4 September 2007 (EDT)

Attentive paranoia, Counterespionage, and Freedom Lights

I am realizing that the planned implementation of Bitfrost is going to prevent fundamental forms of sharing that are broadly desirable (sharing of libraries and media across Activities, higher-level activities that allow recombination and new views of the output of other Activities). I previously read a number of elements of the Bitfrost spec with generous assumptions about the attention to sharing that bitfrost defaults would support. I believe that the activity and dynamics of sharing, and the flow of information through a network of laptops, is not privileged at all in the current implementation; below is an accordingly close reading and response to the original spec [along with more generous possible implementations of the same principles]. Sj talk

security on the machines must be behind the scenes, making its presence known only through subtle visual or audio cues, and never getting in the user's way. Whenever in conflict with slight user convenience, strong unobtrusive security is to take precedence, though utmost care must be taken to ensure such allowances do not seriously or conspicuously reduce the usability of the machines.

It is a mistake here to include "letting activities see one anothers files" with other forms of security. One of the core facets of usability of the machines is the ease and transparency with which files, projects, and activities can be shared. A projected slight improvement in user interface convenience should not of itself lead to preventing ease of reuse. Sj talk

As an example, if a program is found attempting to violate a security setting, the user will not be prompted to permit the action; the action will simply be denied. If the user wishes to grant permission for such an action, she can do so through the graphical security center interface.

Some visible record of ways in which a program has attempted to violate security settings should be useful -- including subtle visualizations during execution and summaries afterwards. Sj talk

Sj talk 14:37, 27 September 2007 (EDT)

Counterespionage

One of the use cases I have often heard proposed is a rogue Activity asking for read access to all the files it can view on the XO, and then posting them to a dastardly archiver that longs to spy on people's shared files. I don't know what the perceived impact of this is, but that strikes me as worrying about a spider that visits someone's website and posts everything it can find there to said dastard. It happens all the time, often for very friendly and productive purposes; I've never met someone who kept my shared data for evil uses (though I suppose they would keep those uses secret, wouldn't they?); and this is what universal sharing means.

If you want to draw a strong cordon around the locally-shared mesh, and make it hard for Activities and people to push things out to the global web, that's fine as well; now the dastardly collector-of-shared-files is someone in my community; again, I think it is a few orders of magnitude more likely that the uses for this kind of collection or aggregation are interesting and well-intentioned, and among the core interactions that both have produced the modern social web and that we want to support.

So I would like to highlight the "Publish" action, one that should be promoted and supported more actively than the "Create and lock" action. These are machines designed for sharing and collaboration; let's make sure they are great at that before finding new ways to secure their data.

Sj talk 14:11, 30 September 2007 (EDT)

Freedom lights

Just as we have security lights over the mic and camera to let people know when their mics and cameras are on, we should have the equivalent of a freedom light that comes on when some sort of DRM or data-sharing restriction is being implemented, so that people can know when they are making things that it will require extra effort to reuse freely. This can be one of the background visual or audio cues; while it may sound like an exceptional measure, it serves the same purpose as the other lights -- as an indication that while writing to disk or having an active input device might suggest those are simply available to the entire machine, files and devices are all often unavailable.

Right now devices and files are unavailable unless explicitly requested; this is stronger than needed, and leads to usability complication; in particular, it means that a freedom light would be on all the time at at least some intensity. On the other hand, one would like that freedom to be influenced by how far afield one's network travels... and files should be able to say "make me available to everyone all the time". Sj talk

OLPC Bitfrost and Bitfrost

OLPC Bitfrost and Bitfrost appear to be closely-related versions of the same document. Am I missing something or should a merge template be placed on OLPC Bitfrost proposing it's merger into Bitfrost? Although OLPC Bitfrost is the longer article (perhaps too long), Bitfrost is more heavily linked and more recently modified (by Walter). I would suggest keeping Bitfrost as the primary page, merging OLPC Bitfrost content into Bitfrost and hunting down the OLPC Bitfrost page refs and re-pointing them. Cjl 14:45, 7 April 2008 (EDT)

I always meant to do a better job of summarizing the longer document on this page... There remains a bit of a skew shift between the version in git and the version in the wiki as well. --Walter 15:01, 7 April 2008 (EDT)

org.freedesktop.DBus.Error.AccessDenied

This came from the devel mailing list. This talk page is probably the best place for it, even though it barely belongs here. It describes harder to diagonose security problems from making a new accounts on a G1G1 laptop. CharlesMerriam 00:23, 9 April 2008 (EDT)

I was going to move this to the Talk:Rainbow page, but it seems that Talk:Rainbow is a redirect to the git overview of Rainbow. Something else to clean up. --Walter 08:35, 9 April 2008 (EDT)

Maybe there should be a security troubleshooting page. Ah well, better somewhere than nowhere. CharlesMerriam 06:15, 10 April 2008 (EDT)

Paul Frost said on devel: Let me start by saying this is probably a total non-issue, but it's surprising to me, so i mention it here.

i have a recent G1G1 machine, running an almost stock 656. (note the "almost".)

the original problem symptom was that my brightness keys didn't work. the keys themselves are fine, and i could control the brightness with the /proc node, so it was something in between that was broken.

i asked on the support list, to find out what controls brightness, and richard pointed me at sugar. i found the keyhandler code in sugar, and that led me to the sugar logfiles.

shell.log contained messages like this:

  <class 'dbus.exceptions.DBusException'>:
  org.freedesktop.DBus.Error.AccessDenied:  A security policy
  in place prevents this sender from sending this message to
  this recipient, see message bus configuration file (rejected
  message had interface "org.laptop.HardwareManager" member
  "get_display_brightness" error name "(unset)" destination ":1.5")

this led me to thinking about the currently logged in user, which reminded me that...

...i had added myself to the password file. i did this for two reasons -- one was because i needed an account with a password so that i could ssh into the machine, and i wasn't sure what adding a password to "olpc" might do to the console ui. the second reason, we can probably ascribe to vanity -- after all, my initials are "pgf", not "olpc", and that's who i wanted to be when i logged in. so shoot me.  :-)

the "pgf" entry i added shared the 500 uid with "olpc" -- same user, two names. when i first added it, i put it after olpc, and that worked well for ssh, but apparently it didn't satisfy my vanity -- i moved the "pgf" line in front when the '\u' in my bash prompt didn't give the right effect.

so: it turns out that this was the cause of the above dbus exception, and the reason that my brightness keys didn't work. reversing the passwd lines so that my 'pgf' entry comes last makes everything work again.

so, what's the point?

i guess i'm surprised that the security policy would be name-based, rather than uid based. on the other hand, since i was able to edit the passwd file, security was pretty much already blown open. as i say -- probably a non-issue.

i only mention it here so that others won't be surprised if they do something similar, and because it might (but probably won't) surprise someone who understands the security model better than i do.

paul

p.s. there were some other things that didn't work right, that i didn't notice at first. "shutdown" (from the "XO Guy" menu) doesn't work if my 'pgf' line comes first, for instance -- but i didn't notice that because i so often ssh in, and use "shutdown -h now" from the command prompt.

References

• http://en.wikipedia.org/wiki/Kerckhoffs%27_principle