Re: [OLPC Security] Bitfrost and dual-boot
On 30.05.2008 08:34, Albert Cahalan wrote: > On Fri, May 30, 2008 at 1:15 AM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > >> On Thu, May 29, 2008 at 8:45 PM, Albert Cahalan <[EMAIL PROTECTED]> wrote: >> >>> On Thu, May 29, 2008 at 5:07 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote: >>> >>> 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. >> 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. > 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. > 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
On 30.05.2008, at 19:38, C. Scott Ananian wrote: > In any case, the best response is clear: continue to work on the Linux > software stack and ensure that it is simply better than the Windows > alternative. I've heard a lot of sturm und drang, but am saddened > that I haven't seen much help from those shouting in actually making > Sugar/Linux more competitive: > http://dev.laptop.org/ticket/5452 > http://dev.laptop.org/ticket/5451 > (as well as the task lists I've previously posted at: > http://lists.laptop.org/pipermail/devel/2008-May/014539.html (end > of message) > http://lists.laptop.org/pipermail/devel/2008-May/0136 ) +5 on that. Just being free and open doesn't cut it, it actually has to be at least as good as the proprietary software for the users. Let's hope some more folk from the peanut gallery joins us down here in the arena. We need people like Albert who do both - criticize *and* contribute, like he did with libsugarize which still is the simplest thing to get regular apps running as an activity. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
On 5/30/08, Albert Cahalan <[EMAIL PROTECTED]> wrote: > I can't imagine that a contract would mention it. It does. The Windows-only trials are "phase I", and the dual-boot "phase II" is explicitly spelled out, with transition criteria to move to phase II related to the completion of OFW2. We raised questions about the contract language during the last all-hands meeting, and were assured that it was closely examined in response. I'm not a lawyer, and haven't seen the language in any case, so I can't say more. But the parties involved were not naive. In any case, the best response is clear: continue to work on the Linux software stack and ensure that it is simply better than the Windows alternative. I've heard a lot of sturm und drang, but am saddened that I haven't seen much help from those shouting in actually making Sugar/Linux more competitive: http://dev.laptop.org/ticket/5452 http://dev.laptop.org/ticket/5451 (as well as the task lists I've previously posted at: http://lists.laptop.org/pipermail/devel/2008-May/014539.html (end of message) http://lists.laptop.org/pipermail/devel/2008-May/0136 ) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
On 5/30/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Thu, 29 May 2008, C. Scott Ananian wrote: > > 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 -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On 29/05/08 23:45 -0400, Albert Cahalan wrote: > > 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 is right - the ability to use OFW (either standalone or as a payload) instead of a proprietary BIOS _is_ of intense interest to PC vendors. I'm excited about it, and I know I can speak for the rest of the coreboot development team when I say they also are excited. But don't overestimate our excitement. We are happy because this gives us a reasonable alternative to a proprietary BIOS, not because we think that we're going to strike some sort of righteous blow against proprietary BIOS companies. The Coreboot / OFW projects don't want to take over the world (though I can't speak for Mitch and his aspirations). All we want to do is provide a quality option for people to chose if they wish. Not everybody will choose it, and as Stuart Smalley said, thats okay. We are closer to that then we ever have been before to providing this, and on behalf of the Coreboot team and the x86 users of the world, I would like to thank Mitch and Jim and the OLPC staff for supporting this effort. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
On 30.05.2008, at 07:33, [EMAIL PROTECTED] wrote: > On Thu, 29 May 2008, C. Scott Ananian wrote: > >> On Thu, May 29, 2008 at 6:03 PM, Michael Stone <[EMAIL PROTECTED]> >> wrote: >>> On Thu, May 29, 2008 at 05:53:49PM -0400, Michael Stone wrote: On Thu, May 29, 2008 at 02:58:07PM -0600, Jameson Chema Quinn wrote: 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 - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Code of Conduct (was Re: Bitfrost and dual-boot)
On Fri, May 30, 2008 at 11:04:57AM +0200, Morgan Collett wrote: > [+cc: Mako] > > Selective quoting: > > On Fri, May 30, 2008 at 7:15 AM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > > You're on crack, Albert. > ... > > Albert, I'm not talking to you any more until you start making > sense. As a side comment, I think this reference to crack is significantly different to the penultimate reference[1,2], although it might have been intended to (humourously?) echo that prior reference. > There is an alarming tendency to attack others on this project in > public, as if that gives some credibility to the argument. I don't see any such tendency, nor do I find what I've seen in the last few months alarming. Of course that's just me, and I'm "not no one" in this project. > Since our project is not only open but also for children, we should be > doubly motivated to treat each other with the respect that we want to > model for the children of the world. Would you say the same things if > you were standing in the middle of a classroom of kids? Laudable sentiment - with which I agree, but I worry that the tension with "get the right information out quickly and eliminate FUD" (with which I also agree) will be unproductive. The solution to bad speech is more speech, not less[3], and I think such a code of conduct might be a solution to a problem this list doesn't have. I'm talking about devel@ specifically, though this probably goes (less well but still) for other lists. Often the people most in the know are those with the least time, and if they have to bend over backwards to not offend any/all questions, they'll respond (IMO) by communicating less, rather than "better" (according to the Code of Conduct guidelines). > I want to encourage ALL who see this email to read the Ubuntu code of > conduct (once again, http://www.ubuntu.com/community/conduct) and make > a personal commitment to abide by the spirit of it until such time as > we formally introduce one. I think everyone tries for this, as they know that if others find them to be like an idiot/prat, people they care about communicating with will pay less attention to them in the future. Perhaps just making people aware of it and that a person as involved as yourself considers it an important set of guidelines will get you/us most of the benefit that making people sign it would (not that I want to say that's what you're advocating, necessarily). > Regards > Morgan Martin 1. http://lists.laptop.org/pipermail/devel/2008-May/013763.html 2. http://lists.laptop.org/pipermail/devel/2008-May/014798.html 3. LAURENCE H. TRIBE, AMERICAN CONSTITUTIONAL LAW 834 (2d ed. 1988) via http://findarticles.com/p/articles/mi_qa3736/is_21/ai_n8887519/pg_18 quoted in http://findarticles.com/p/articles/mi_qa3736/is_21/ai_n8887519 though there is a counterargument presented in the latter link (that's not applicable here, I think). pgpaBQKXU6noK.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Code of Conduct (was Re: Bitfrost and dual-boot)
[+cc: Mako] Selective quoting: On Fri, May 30, 2008 at 7:15 AM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > You're on crack, Albert. ... > Albert, I'm not talking to you any more until you start making sense. Not to pick on you personally Edward, this just triggered something: I've long thought we need an equivalent of the Ubuntu code of conduct in the OLPC / Sugar communities: http://www.ubuntu.com/community/conduct - written by Mako (http://mako.cc/copyrighteous/20071112-00) There should be no excuse for personal attacks, insults, or anger directed at individuals, whether in public or private correspondence - but especially in public. Disputes should always be resolved in private, if possible. There is an alarming tendency to attack others on this project in public, as if that gives some credibility to the argument. Since our project is not only open but also for children, we should be doubly motivated to treat each other with the respect that we want to model for the children of the world. Would you say the same things if you were standing in the middle of a classroom of kids? I want to encourage ALL who see this email to read the Ubuntu code of conduct (once again, http://www.ubuntu.com/community/conduct) and make a personal commitment to abide by the spirit of it until such time as we formally introduce one. As for me, I digitally signed it to become an "Ubuntero" years ago and am now an Ubuntu member. We would do well to emulate the governance structures of the Ubuntu community, which have successfully scaled to a large and ever-growing positive community. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Fri, May 30, 2008 at 1:15 AM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 8:45 PM, Albert Cahalan <[EMAIL PROTECTED]> wrote: >> On Thu, May 29, 2008 at 5:07 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote: >>> On Thu, May 29, 2008 at 10:48 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote: >> 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. > 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. >> 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. > 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. >> 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. > 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. > 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. >>> 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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
On Thu, 29 May 2008, C. Scott Ananian wrote: > On Thu, May 29, 2008 at 6:03 PM, Michael Stone <[EMAIL PROTECTED]> wrote: >> On Thu, May 29, 2008 at 05:53:49PM -0400, Michael Stone wrote: >>> On Thu, May 29, 2008 at 02:58:07PM -0600, Jameson Chema Quinn wrote: >>> 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? David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, May 29, 2008 at 8:45 PM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 5:07 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote: >> On Thu, May 29, 2008 at 10:48 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > >>> 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? >>> (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. > 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? > 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. -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to prevent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
Microsoft either will or won't use the NAND for its own purposes. However a third option beyond the "dual boot" or "engulf and devour" choices so far described, for a deployment that is more school-centric and less oriented toward laptop autonomy than the OLPC vision, would be to use network file storage. With that model, school servers used as filers would potentially provide much more storage than would be practical in the laptops. Limited space on the laptop could be used as a cache. While this diverges from the educational philosophy of OLPC, it is quite consistent with how laptops are used in many (most?) American schools. It places some additional power demands at the schools, but I'd put some money on that being at least part of their model anyway. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
On Thu, May 29, 2008 at 7:31 PM, Bobby Powers <[EMAIL PROTECTED]> wrote: > On Fri, May 30, 2008 at 12:39 AM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: >> * 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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, May 29, 2008 at 5:07 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 10:48 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote: >> 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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, May 29, 2008 at 5:05 PM, Arne Babenhauserheide <[EMAIL PROTECTED]> wrote: > Am Freitag 30 Mai 2008 01:44:29 schrieb Edward Cherlin: > >> > I don't often write here, but at the moment I don't see why BitFrost >> > should be used in the first case (except, because we _can_). >> >> Because of governments that will not buy unprotected laptops for >> schoolchildren. > > But they buy them with Windows... ;) > > Still, that is a reason I understand. > > >> And if the government installs Windows on your XO, whose problem is it >> then? If it was just people, we wouldn't be having this argument. > > That depends on whether the government and schools can lock children in > Windows. Governments can, and some very likely will require that certain lessons be given in Windows. >> > Or did I miss Windows getting preinstalled on every XO or something >> > similarly absurd? >> >> Yes, you did. Egypt in particular demanded dual-boot XOs for all of >> its students. > > Ouch, that's really painful. > > Seems I did miss quite much, when I didn't have time to read my mails... > > > Many thanks for getting me up to date, > Arne Think nothing of it. -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
Am Freitag 30 Mai 2008 01:44:29 schrieb Edward Cherlin: > > I don't often write here, but at the moment I don't see why BitFrost > > should be used in the first case (except, because we _can_). > > Because of governments that will not buy unprotected laptops for > schoolchildren. But they buy them with Windows... ;) Still, that is a reason I understand. > And if the government installs Windows on your XO, whose problem is it > then? If it was just people, we wouldn't be having this argument. That depends on whether the government and schools can lock children in Windows. > > Or did I miss Windows getting preinstalled on every XO or something > > similarly absurd? > > Yes, you did. Egypt in particular demanded dual-boot XOs for all of > its students. Ouch, that's really painful. Seems I did miss quite much, when I didn't have time to read my mails... Many thanks for getting me up to date, Arne signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, May 29, 2008 at 2:25 PM, Arne Babenhauserheide <[EMAIL PROTECTED]> wrote: > Am Donnerstag 29 Mai 2008 23:07:23 schrieb Edward Cherlin: >> 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. > > I don't often write here, but at the moment I don't see why BitFrost should be > used in the first case (except, because we _can_). Because of governments that will not buy unprotected laptops for schoolchildren. > Why protect GNU/Linux from Windows? > > If people install Windows on their XOs, then it's their problem. And if the government installs Windows on your XO, whose problem is it then? If it was just people, we wouldn't be having this argument. > And the Virus/BotNet/... can't spread to not Windows infected XOs, so there's > no reason to be afraid. > > Or did I miss Windows getting preinstalled on every XO or something similarly > absurd? Yes, you did. Egypt in particular demanded dual-boot XOs for all of its students. I guess you didn't notice us telling Nicholas he was insane a few weeks ago, before it became clear that there were to be no Windows-only XOs after the initial trials in the next month and a half, and nobody at OLPC would be expected to participate in porting Sugar to Windows. Then the shouting subsided to angry muttering in corners. > Best wishes, > Arne > -- > Unpolitisch sein > Heißt politisch sein > Ohne es zu merken. > - Arne Babenhauserheide ( http://draketo.de ) > > -- Weblog: http://blog.draketo.de > -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the > history of free software. > -- Ein Würfel System: http://1w6.org - einfach sauberere (Rollenspiel-) Regeln > > -- Mein öffentlicher Schlüssel (PGP/GnuPG): > http://draketo.de/inhalt/ich/pubkey.txt > -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
On Fri, May 30, 2008 at 12:39 AM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 6:03 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > > On Thu, May 29, 2008 at 05:53:49PM -0400, Michael Stone wrote: > >> On Thu, May 29, 2008 at 02:58:07PM -0600, Jameson Chema Quinn wrote: > >> 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. > 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. Bobby > > * 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 > > -- > ( http://cscott.net/ ) > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
Am Donnerstag 29 Mai 2008 23:58:04 schrieben Sie: > Yes, you did (where have you been hiding =) ). Windows will come > preinstalled on XO's at the client's request. And in developing countries > the paying clients (ministries of eductaion, etc.) receive technical advice > and counsel mostly from Microsoft. But that's "at the clients request" (fits what I remembered), which will come at a quickly reducing rate, when Windows corrupts GNU/Linux, at least I hope so. It's not "in all", and it certainly isn't something which can't be fixed easily by anyone owning an XO. And it will be children who use the XO, and they can fix their XOs themselves, so the "counselled" ministries should not be able to restrict the use of XOs. There's a lot of development potential in the users of the XOs, and harnessing that for the free platform should hopefully make Windows unattractive. I think it's better not to implement anything which can protect GNU/Linux from Windows, because Windows could use the same for the parts it corrupts. That naturally shouldn't stop thinking about it to be a step ahead of Windows and to be able to avoid the danger of people getting stuck with any proprietary OS by means of some kind of "protection" originally meant to avoid that danger. It's just that, in my humble opinion, any mechanism which might limit the software which can be installed on an XO by its user should be checked thrice, and then in most cases discarded. Best wishes, Arne -- Unpolitisch sein Heißt politisch sein Ohne es zu merken. - Arne Babenhauserheide ( http://draketo.de ) -- Weblog: http://blog.draketo.de -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the history of free software. -- Ein Würfel System: http://1w6.org - einfach sauberere (Rollenspiel-) Regeln -- Mein öffentlicher Schlüssel (PGP/GnuPG): http://draketo.de/inhalt/ich/pubkey.txt signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
On Thu, May 29, 2008 at 6:03 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 05:53:49PM -0400, Michael Stone wrote: >> On Thu, May 29, 2008 at 02:58:07PM -0600, Jameson Chema Quinn wrote: >> 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 -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] Bitfrost and dual-boot
On Thu, May 29, 2008 at 05:53:49PM -0400, Michael Stone wrote: > On Thu, May 29, 2008 at 02:58:07PM -0600, Jameson Chema Quinn wrote: > 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, May 29, 2008 at 11:25:05PM +0200, Arne Babenhauserheide wrote: > Am Donnerstag 29 Mai 2008 23:07:23 schrieb Edward Cherlin: > > The question was, how to protect Linux from Windows, in particular > > Why protect GNU/Linux from Windows? > > If people install Windows on their XOs, then it's their problem. > > And the Virus/BotNet/... can't spread to not Windows infected XOs, so > there's no reason to be afraid. Yah, that's a good point. It is easy to reinstall GNU/Linux and recover from backup. If virii and botnets and corruption of GNU/Linux are part of the Windows experience, so much the better. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, May 29, 2008 at 02:58:07PM -0600, Jameson Chema Quinn wrote: > > 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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
Am Donnerstag 29 Mai 2008 23:07:23 schrieb Edward Cherlin: > 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. I don't often write here, but at the moment I don't see why BitFrost should be used in the first case (except, because we _can_). Why protect GNU/Linux from Windows? If people install Windows on their XOs, then it's their problem. And the Virus/BotNet/... can't spread to not Windows infected XOs, so there's no reason to be afraid. Or did I miss Windows getting preinstalled on every XO or something similarly absurd? Best wishes, Arne -- Unpolitisch sein Heißt politisch sein Ohne es zu merken. - Arne Babenhauserheide ( http://draketo.de ) -- Weblog: http://blog.draketo.de -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the history of free software. -- Ein Würfel System: http://1w6.org - einfach sauberere (Rollenspiel-) Regeln -- Mein öffentlicher Schlüssel (PGP/GnuPG): http://draketo.de/inhalt/ich/pubkey.txt signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, 29 May 2008, Jameson "Chema" Quinn wrote: > >> 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? the terminal activity can, and if it can why can't everything else use the same mechanism? and there's always sudo /bin/sh available >> >> not to mention the fact that you would need to audit every program to see >> what it will do with the data you feed it (if anything reads something from >> a file and then executes arbatrary commands based on it, you've lost) >> > > If it switches to run as another user (or otherwise reduces its own > destructive capabilities) before doing so, not so. This is the principle > that Bitfrost is built on: ways to run untrusted code. > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, May 29, 2008 at 10:48 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > Jameson "Chema" Quinn writes: > >> 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. > ... >> 2. By writing to OS 1's file system, > > 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. Imagine the botnet you could create by implementing a Borgfrost[TM] hack! And then it would propagate via the mesh! 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. > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
> 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? > > not to mention the fact that you would need to audit every program to see > what it will do with the data you feed it (if anything reads something from > a file and then executes arbatrary commands based on it, you've lost) > If it switches to run as another user (or otherwise reduces its own destructive capabilities) before doing so, not so. This is the principle that Bitfrost is built on: ways to run untrusted code. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, 29 May 2008, Jameson "Chema" Quinn wrote: > 2008/5/29 <[EMAIL PROTECTED]>: > >> On Thu, 29 May 2008, Jameson "Chema" Quinn wrote: >> >> I just had an IRC conversation with Benjamin Schwarz in which we talked >>> about: >>> >>> He said that 3,4, and 5 have been considered more serious than 1 and 2; >>> since they are impossible, there is little point doing 1 and 2. I >>> disagreed. >>> >>> There is no way with current hardware to write-protect the NAND storage, >>> and >>> not too much space (<<512K) in the firmware storage. However, it would be >>> possible to hash NAND or some subset thereof, and complain loudly on boot >>> if >>> it changed. >>> >> >> not really, you would have to hash NAND on every shutdown. remember >> everything you do is in thr journal on NAND, and any change (including >> things like a file timestamp, including atime) will invalidate your hash. >> >> David Lang >> >> The idea would be to have a separate read-only volume on NAND, which > included everything executable as root (in other words, 90-100% of glucose > and ribose; the kernel, though, is already signed, so could be elsewhere). > Mounting this ro would prevent silly atime breakage, and there could be > strong protections to prevent anything NOT on this volume from being > considered "executable" by root. (Of course, this is not the whole story, as > there are uncountable ways for non-"executable" stuff to compromise > security; but it is a start. It would break any rpm's that only know how to > run as root - but these are broken anyway.) if you run everything as user olpc and user olpc can become root without a password, getting olpc is as good as getting root. so you have to check everything that could run as user olpc as well. not to mention the fact that you would need to audit every program to see what it will do with the data you feed it (if anything reads something from a file and then executes arbatrary commands based on it, you've lost) given that this would prevent anywone from writing or modifying any software on the machine, this conflicts quite explicitly with the goals of the project. the best you can do is to protect the firmware, and give the firmware a way to re-image the NAND so that you can be sure of recovering from any corruption. you are not going to be able to prevent it. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
2008/5/29 <[EMAIL PROTECTED]>: > On Thu, 29 May 2008, Jameson "Chema" Quinn wrote: > > I just had an IRC conversation with Benjamin Schwarz in which we talked >> about: >> >> He said that 3,4, and 5 have been considered more serious than 1 and 2; >> since they are impossible, there is little point doing 1 and 2. I >> disagreed. >> >> There is no way with current hardware to write-protect the NAND storage, >> and >> not too much space (<<512K) in the firmware storage. However, it would be >> possible to hash NAND or some subset thereof, and complain loudly on boot >> if >> it changed. >> > > not really, you would have to hash NAND on every shutdown. remember > everything you do is in thr journal on NAND, and any change (including > things like a file timestamp, including atime) will invalidate your hash. > > David Lang > > The idea would be to have a separate read-only volume on NAND, which included everything executable as root (in other words, 90-100% of glucose and ribose; the kernel, though, is already signed, so could be elsewhere). Mounting this ro would prevent silly atime breakage, and there could be strong protections to prevent anything NOT on this volume from being considered "executable" by root. (Of course, this is not the whole story, as there are uncountable ways for non-"executable" stuff to compromise security; but it is a start. It would break any rpm's that only know how to run as root - but these are broken anyway.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, 29 May 2008, Jameson "Chema" Quinn wrote: I just had an IRC conversation with Benjamin Schwarz in which we talked about: He said that 3,4, and 5 have been considered more serious than 1 and 2; since they are impossible, there is little point doing 1 and 2. I disagreed. There is no way with current hardware to write-protect the NAND storage, and not too much space (<<512K) in the firmware storage. However, it would be possible to hash NAND or some subset thereof, and complain loudly on boot if it changed. not really, you would have to hash NAND on every shutdown. remember everything you do is in thr journal on NAND, and any change (including things like a file timestamp, including atime) will invalidate your hash. David Lang Blanking RAM on reboot, and keeping the private key in firmware instead of NAND are also possible. There is little point spending much energy on this issue until more of Bitfrost is in place. Once this becomes salient, it might be worth doing something along these lines. Also, it might be another good argument against dual-boot, especially with highly insecure OS's like Windows. On Thu, May 29, 2008 at 11:48 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote: Jameson "Chema" Quinn writes: 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. ... 2. By writing to OS 1's file system, 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) I did not hope to protect all of it. I hoped to use encryption and/or signatures to limit the kinds of damage that could be done. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, May 29, 2008 at 2:08 PM, Morgan Collett <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008 at 7:48 PM, Albert Cahalan <[EMAIL PROTECTED]> wrote: >> Jameson "Chema" Quinn writes: >>> 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. >> ... >>> 2. By writing to OS 1's file system, >> >> 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. > > Windows does not need to use the NAND flash with the dual boot setup. > > From Monday's OLPC News mail on the community-news list > (http://lists.laptop.org/pipermail/community-news/2008-May/000128.html): > >> Mitch Bradley: >> * Reports that dual boot is working. You can plug in an SD card to >> boot Windows, then remove it to boot back to Linux. > > This of course using OFW2 which is not yet released. This morning on IRC however, Mitch says "that other OS uses NAND". It sure is odd how so many people continue to think that Microsoft would not do everything in their power to prevent dual-boot. Three decades of evidence is against that silly fantasy. This is war to them, and they take full advantage of every friendly gesture we make. Above all, they want platform(*) control. In this case however, malice is not even required. The NAND would make a nice place for swapping. * FYI, "platform": ABI, API, protocols, file formats... (thus the opposition to portable runtime layers like Sugar, Java, Sugar, Borland's OWL classes, Sugar, POSIX, and Sugar) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
I just had an IRC conversation with Benjamin Schwarz in which we talked about: He said that 3,4, and 5 have been considered more serious than 1 and 2; since they are impossible, there is little point doing 1 and 2. I disagreed. There is no way with current hardware to write-protect the NAND storage, and not too much space (<<512K) in the firmware storage. However, it would be possible to hash NAND or some subset thereof, and complain loudly on boot if it changed. Blanking RAM on reboot, and keeping the private key in firmware instead of NAND are also possible. There is little point spending much energy on this issue until more of Bitfrost is in place. Once this becomes salient, it might be worth doing something along these lines. Also, it might be another good argument against dual-boot, especially with highly insecure OS's like Windows. On Thu, May 29, 2008 at 11:48 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > Jameson "Chema" Quinn writes: > > > 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. > ... > > 2. By writing to OS 1's file system, > > 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) I did not hope to protect all of it. I hoped to use encryption and/or signatures to limit the kinds of damage that could be done. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On Thu, May 29, 2008 at 7:48 PM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > Jameson "Chema" Quinn writes: > >> 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. > ... >> 2. By writing to OS 1's file system, > > 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. Windows does not need to use the NAND flash with the dual boot setup. >From Monday's OLPC News mail on the community-news list (http://lists.laptop.org/pipermail/community-news/2008-May/000128.html): > Mitch Bradley: > * Reports that dual boot is working. You can plug in an SD card to > boot Windows, then remove it to boot back to Linux. This of course using OFW2 which is not yet released. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
Jameson "Chema" Quinn writes: > 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. ... > 2. By writing to OS 1's file system, 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. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
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ć < [EMAIL PROTECTED]> wrote: > On May 28, 2008, at 8:33 PM, Benjamin M. Schwartz wrote: > >> 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ć <[EMAIL PROTECTED]> | http://radian.org > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
On May 28, 2008, at 8:33 PM, Benjamin M. Schwartz wrote: > 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ć <[EMAIL PROTECTED]> | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost and dual-boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What are you trying to prevent? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg9+cYACgkQUJT6e6HFtqSEywCghEZc2W4v3996TeIDb5VSPoJf p2wAnjSKfEx4LEt7lHJgDbr4T6WBIBKm =SwvH -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Bitfrost and dual-boot
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
