olpc-security
hi, what is the use of file : /etc/olpc-security ? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: olpc-security
On 17.02.2010, at 14:58, Esteban Arias wrote: hi, what is the use of file : /etc/olpc-security ? When /etc/olpc-security exists, Sugar uses Rainbow to isolate activity instance from each other. This is one of the XO's security features. See http://wiki.laptop.org/go/Rainbow - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] permissions for setting scheduler policy
A typical solution is, when you are about to start the process, invoke a different (very small, so it can be audited) process that can set what you need as root, and then drop the privileges before execing the real image that does the work. But Michael may have something else in mind for Rainbow. - Jim On Wed, 2008-08-13 at 11:21 +0100, Victor Lazzarini wrote: Hello everyone, I am working on trying to get better RT performance off csound. I have added some code to set the scheduler policy and priority, but the problem is that I can only use it as root. As user olpc, the scheduler code will not be allowed to set the policy and priority. It'd be ideal if activities using csound could take advantage of this code, because it seems to help performance. We could set up group permissions for that in /etc/security/limits.conf What are your thoughts (esp. Deepak and Daniel D)? Dr Victor Lazzarini Senior Lecturer Music Technology Laboratory, Music Department National University of Ireland, Maynooth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] permissions for setting scheduler policy
yes, I suppose that can be done, but it does look a little messy, and it would be nice to be able to write activities that transparently can do this, rather than as special cases. It does not need to be root. I can set permissions for user olpc and it works (provided that limits.conf is edited correctly). But somehow activities (launched by rainbow?) are UID 10002 which seems not to follow the rules of pam . Victor At 15:43 14/08/2008, Jim Gettys wrote: A typical solution is, when you are about to start the process, invoke a different (very small, so it can be audited) process that can set what you need as root, and then drop the privileges before execing the real image that does the work. But Michael may have something else in mind for Rainbow. - Jim On Wed, 2008-08-13 at 11:21 +0100, Victor Lazzarini wrote: Hello everyone, I am working on trying to get better RT performance off csound. I have added some code to set the scheduler policy and priority, but the problem is that I can only use it as root. As user olpc, the scheduler code will not be allowed to set the policy and priority. It'd be ideal if activities using csound could take advantage of this code, because it seems to help performance. We could set up group permissions for that in /etc/security/limits.conf What are your thoughts (esp. Deepak and Daniel D)? Dr Victor Lazzarini Senior Lecturer Music Technology Laboratory, Music Department National University of Ireland, Maynooth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child Victor Lazzarini Music Technology Laboratory Music Department National University of Ireland, Maynooth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] preliminary [PATCH] and discussion for #5657: activity isolation for all activities in ~/Activities
On Fri, Aug 1, 2008 at 5:01 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: Problem: anything named Journal, Terminal, Log, or Analyze is not isolated. This is the biggest security hole we have right now: it is a trivial way for any activity to get root access. Another possible short-term hack is to simple disable activitybundle.install() and activitybundle.upgrade() for bundes with bundle_ids matching those of Journal, Terminal, Log, or Analyze. This allows these activities to be installed in /home/olpc/Activites with a customization key, as usual, but prevents malicious attackers from using a web link or the activity updater to replace the originally-installed versions. This has the benefit of (a) not requiring us to revisit the activities in /home war, and (b) allowing us to upgrade the versions of these trusted activities in /home in (say) 9.1, using the proper mechanism. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] preliminary [PATCH] and discussion for #5657: activity isolation for all activities in ~/Activities
On Fri, Aug 1, 2008 at 4:01 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Fri, Aug 1, 2008 at 5:01 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: Problem: anything named Journal, Terminal, Log, or Analyze is not isolated. This is the biggest security hole we have right now: it is a trivial way for any activity to get root access. Another possible short-term hack is to simple disable activitybundle.install() and activitybundle.upgrade() for bundes with bundle_ids matching those of Journal, Terminal, Log, or Analyze. This allows these activities to be installed in /home/olpc/Activites with a customization key, as usual, but prevents malicious attackers from using a web link or the activity updater to replace the originally-installed versions. This has the benefit of (a) not requiring us to revisit the activities in /home war, and (b) allowing us to upgrade the versions of these trusted activities in /home in (say) 9.1, using the proper mechanism. --scott I like this idea. Of course, it means that can install using cp -r, including installing a trojan activity which does not *look* like Terminal. ... My patch has activities requesting P_ROOT in activity.info. Could we simply refuse to do a normal install for such activities? We could even keep a list of them, and not respect what's not on the list, and only update the list on a keyed install. This is not as secure as signatures, because a sneaky attack could still modify the contents of an installed activity, but it is getting pretty close. Jameson ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] SuperUser permission for the Driver??
On Thu, 26 Jun 2008, Deepak Saxena wrote: On Jun 25 2008, at 14:01, Carl-Daniel Hailfinger was caught saying: On 25.06.2008 08:07, Michael Stone wrote: We have an activity that wants superuser privilege in order to poke kernel memory. Hello? Please take the poor activity out back and shoot it. No activity has any business poking kernel memory. What if I replace Michael's statement with some specific use cases: - An activity requires a specific device driver module to be (un)loaded to properly function and loading this driver requires su privilege. or: - An activity requires a device to switch operation modes and that operation mode is configured via a sysfs file. The file is poked by a library API, but it requires su privilege to do so. I agree with Paul that we need to have a solution to these cases iff we want to support running arbitrary software and hw combinations on the XO. The other option is to limit the scope of the system to a very specific set of sw and hw, treating the XO as embedded education appliance instead of a general-purpose laptop device, which I don't think we want to do. It can be a general purpose laptop. And we need not surrender our common sense: if we want the thing to be better, it will have to be different. In particular, it cannot have kernel modules promiscuously loaded and unloaded. Thus not all software will run on the laptop. But that is already the case for the most widely distributed home systems: a Microsoft program will not run on GNU/Linux, an Apple program will not run on a Microsoft OS, etc.. I don't have any immediate answers to any of Michael's questions but I think looking at how the standard ditros deal with this would be a starting point. ~Deepak The usual free Unices' security apparatus is ludicrously inadequate. The XO system should be much better. oo--JS. -- Deepak Saxena [EMAIL PROTECTED] ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] SuperUser permission for the Driver??
On Thu, 26 Jun 2008, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Deepak Saxena wrote: | I agree with Paul that we need to have a solution to these | cases iff we want to support running arbitrary software and | hw combinations on the XO. The other option is to limit the | scope of the system to a very specific set of sw and hw, | treating the XO as embedded education appliance instead of | a general-purpose laptop device, which I don't think | we want to do. That is _precisely_ what I want to do. OLPC's goal is to distribute XOs to the poorest children in the world. That means that in the category of electronics, the great majority will have the XO and nothing else. Peripherals are a rarity, an edge case. There is a planned design to allow the user to grant extra privileges to different Activities, but those privileges will probably never extend to loading arbitrary kernel modules. I have no problem declaring that anyone who is modifying the kernel is a developer, and should therefore get a devkey and call modprobe themselves. - --Ben Yes. oo--JS. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhjw/AACgkQUJT6e6HFtqQlSgCfbDujhumR3cmtT/MpEH8qQidC cYEAn0atipCHDcuYjAIvS/E6IpxD0Ktb =WJse -END PGP SIGNATURE- ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
I would like to see the link for requesting a developer key made much more prominent in the library. I'd like to see the pathname to downloading the key itself much more prominent (and displayed in a larger point size) on the webpage returned after the request is granted. For those of us with aging eyes, it is almost impossible to read, even in BW mode. In the case of old builds, Terminal doesn't not accept paste from the clipboard, so the wget cmd has to be transcribed by hand. (My workaround is to paste into Write and scale the font.) -walter --- I'll file a ticket. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
The two issues that I am concerned about regarding the write protect flag with regards to G1G1: 1 - I thought requiring signed images was part of our bitfrost security. Doesn't it provide some protection from malicious images? Assuming we get to the point where upgrading is an easy click from the G1G1 machine, then we want to be sure that people don't mistakenly load non-signed images. If you are not a developer; doesn't this add a level of protection that we want for 90% of G1G1 recipients? 2 - I believe our support issues will go up significantly as people who have little or no experience are encouraged to download all sorts of untested builds with no easy way to get back to a working system. To feel better about the support issues, I would like the one-button push that restores a laptop to factory default. Actually walking people through a cleaninstall is a very time-consuming process right now. Finally, I agree with Scott, that the easiest thing we can do in the short term is to make the 'get a developer key' more prominent for those who want to find it. I would really like a brief note about how they should first be familiar with how to do a factory cleaninstall before they unprotect their machine. Kim On Wed, Jun 4, 2008 at 9:50 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 9:20 PM, reynt0 [EMAIL PROTECTED] wrote: I also want to be able to examine the XO as thoroughly as possible from my own (USA, educated, experienced, and so on) perspective. In that regard, FWIW I found the various infos I later could find from olpc a bit unclear or even seeming at first glance inconsistent about how usable a G1G1 XO could be as-delivered. My present understanding is that I will need a developer's key, and that I can get one by asking when I'm ready to (though I'm not sure if I would be able to if I were a non-compsci G1G1), tho I am willing to accept that this understanding may be wrong. http://wiki.laptop.org/go/Developer_key I would like to see the link for requesting a developer key made much more prominent in the library. (I've cc'ed SJ specifically to see if he can make that happen for me.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
Kim Quirk [EMAIL PROTECTED] writes: [...] Finally, I agree with Scott, that the easiest thing we can do in the short term is to make the 'get a developer key' more prominent for those who want to find it. [...] Taking away the 24 hour delay between key request and response could help solve both problems. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On Thu, 5 Jun 2008, Kim Quirk wrote: 1 - I thought requiring signed images was part of our bitfrost security. Doesn't it provide some protection from malicious images? Assuming we get to the point where upgrading is an easy click from the G1G1 machine, then we want to be sure that people don't mistakenly load non-signed images. If you are not a developer; doesn't this add a level of protection that we want for 90% of G1G1 recipients? how about an option to install a 'tester key' that would let a machine download test builds that are then signed by a different key then the production builds. by comparison a developer key would let them install anything. 2 - I believe our support issues will go up significantly as people who have little or no experience are encouraged to download all sorts of untested builds with no easy way to get back to a working system. To feel better about the support issues, I would like the one-button push that restores a laptop to factory default. Actually walking people through a cleaninstall is a very time-consuming process right now. there is currently a one button reboot to the prior version, so people wiil only need to do a cleaninstall if they install two broken builds in a row, _and_ can't use either build to install a good build (which is unlikely becouse they used the older one to install the one after that, so they should be able to use that older one to install a working build) David Lang Finally, I agree with Scott, that the easiest thing we can do in the short term is to make the 'get a developer key' more prominent for those who want to find it. I would really like a brief note about how they should first be familiar with how to do a factory cleaninstall before they unprotect their machine. Kim On Wed, Jun 4, 2008 at 9:50 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 9:20 PM, reynt0 [EMAIL PROTECTED] wrote: I also want to be able to examine the XO as thoroughly as possible from my own (USA, educated, experienced, and so on) perspective. In that regard, FWIW I found the various infos I later could find from olpc a bit unclear or even seeming at first glance inconsistent about how usable a G1G1 XO could be as-delivered. My present understanding is that I will need a developer's key, and that I can get one by asking when I'm ready to (though I'm not sure if I would be able to if I were a non-compsci G1G1), tho I am willing to accept that this understanding may be wrong. http://wiki.laptop.org/go/Developer_key I would like to see the link for requesting a developer key made much more prominent in the library. (I've cc'ed SJ specifically to see if he can make that happen for me.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ 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: [OLPC Security] G1G1: Security, to enable or disable...
SJ wrote: I continue to be uncomfortable that we are sending out restricted / locked-down machines without a clear need. The arguments made so far for this are 1. Getting G1G1 people to test security steps 2. Protecting G1G1 donors from installing anything but signed builds 3. Showing a pretty boot screen 3. represents a bug that should be fixed. Tying pretty boot to machine-lockdown is arbitrary. agreed. as a G1G1 owner i wanted to see the boot messages quite a long time before i needed or wanted a dev key. 2. assumes that this is the best result for G1G1 donors, which seems unlikely to me. Discovering how to update to anything but the most aggressively promoted builds is already a sign of tech savvy. and that technical savvy will lead them to the developer key, won't it? This protection would still effectively be in place for the vast majority of users for whom it matters if we aggressively recommended to users (say, after a couple of days of use) that they get a developers key if they want full control of their machines for any reason. how would you aggressively recommend anything to a G1G1 user after a couple of days of use? in any case, trust me -- figuring out how to get ofw to boot a new kernel is _way_ harder and scarier than getting the dev key in the first place. :-) 1. is an interesting argument. As with 2, it would still hold if recipients were actively encouraged to get developers keys if they have any interest in having full control of their machines (indeed you could say that they we would have a much better test of the dev-key acquisition process, which currently works more clearly in large batches for countries than for individuals). i would have thought G1G1 proved that dev-key acquisition works just fine. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 64.9 degrees) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On Tue, 3 Jun 2008, C. Scott Ananian wrote: . . . The original reason is that it allowed our G1G1 users to more fully exercise/test our secure boot paths, which are used in our deployment countries. This helps G1G1 users be more representative testers, and . . . I'm a G2G2. Among my interests was to experience as much as possible *exactly* what a deployment-country child would be experiencing when opening an XO for the first time (anticipation, mystery, caution about breaking something in limited supply and special, ...?). If I had any idea while I was opening it about running it like an expert, that wouldn't be the experience. So I was happy about the security state. Computing--and the computing use experience OLPC is sharing around the world--involves a lot more than hardware and software, IMO. I also want to be able to examine the XO as thoroughly as possible from my own (USA, educated, experienced, and so on) perspective. In that regard, FWIW I found the various infos I later could find from olpc a bit unclear or even seeming at first glance inconsistent about how usable a G1G1 XO could be as-delivered. My present understanding is that I will need a developer's key, and that I can get one by asking when I'm ready to (though I'm not sure if I would be able to if I were a non-compsci G1G1), tho I am willing to accept that this understanding may be wrong. (FWIW, I'm on this thread only via the security list.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On Wed, Jun 4, 2008 at 12:15 AM, Paul Fox [EMAIL PROTECTED] wrote: SJ wrote: I continue to be uncomfortable that we are sending out restricted / locked-down machines without a clear need. The arguments made so far for this are 1. Getting G1G1 people to test security steps 2. Protecting G1G1 donors from installing anything but signed builds 3. Showing a pretty boot screen 3. represents a bug that should be fixed. Tying pretty boot to machine-lockdown is arbitrary. agreed. as a G1G1 owner i wanted to see the boot messages quite a long time before i needed or wanted a dev key. http://wiki.laptop.org/go/Cheat_codes the 'check' key is what you are looking for. 1. is an interesting argument. As with 2, it would still hold if recipients were actively encouraged to get developers keys if they have any interest in having full control of their machines (indeed you could say that they we would have a much better test of the dev-key acquisition process, which currently works more clearly in large batches for countries than for individuals). i would have thought G1G1 proved that dev-key acquisition works just fine. That's my hope. Shipping G1G1 with security enabled forced us to properly prioritize bugs with dev key request/fulfillment, and to build tools to make requesting a dev key easy. That was a success, from my perspective. I'd like to be able to offer the same antitheft protection we will be trying to offer Uruguay to G1G1 users as well, on a voluntary basis, and roughly the same reasoning. If something goes wrong or it doesn't work like it should, G1G1 users are communicative and English-literate canaries in the coal mine. And diagnosing and fixing the problem is much easier for G1G1 than it is for some small village in Uruguay a week's walk from anything. But again, my perspective is warped by having to write this code and be confident in its correctness. I want as much help as I can get. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On Wed, Jun 4, 2008 at 9:20 PM, reynt0 [EMAIL PROTECTED] wrote: I also want to be able to examine the XO as thoroughly as possible from my own (USA, educated, experienced, and so on) perspective. In that regard, FWIW I found the various infos I later could find from olpc a bit unclear or even seeming at first glance inconsistent about how usable a G1G1 XO could be as-delivered. My present understanding is that I will need a developer's key, and that I can get one by asking when I'm ready to (though I'm not sure if I would be able to if I were a non-compsci G1G1), tho I am willing to accept that this understanding may be wrong. http://wiki.laptop.org/go/Developer_key I would like to see the link for requesting a developer key made much more prominent in the library. (I've cc'ed SJ specifically to see if he can make that happen for me.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On Tue, Jun 3, 2008 at 12:07 PM, ffm [EMAIL PROTECTED] wrote: Why were G1G1 machines shipped with firmware, kernel, and reflash locks enabled? (see http://wiki.laptop.org/go/Developer_keys ) Theft is not a good reason, as they do not require activation leases. It only seems to be a bother for people who want to help out with the OLPC project. The original reason is that it allowed our G1G1 users to more fully exercise/test our secure boot paths, which are used in our deployment countries. This helps G1G1 users be more representative testers, and did successfully flush out security logistics issues like the ones you seem to be complaining about before they became a big issue for deployment countries. A secondary consideration was that secure boot is tied to pretty boot, since we assume that if you are a developer you won't be scared of boot messages. A non-tech-team charge was to ensure that G1G1 machines looked pretty while booting. This seems trivial to us, but was in fact a big concern for non-developers involved in the program. These issues can probably be revisited before a second G1G1 program, but my personal feeling is that we eventually do have to make the antitheft security stuff just work and not get in ordinary people's way (if you're a developer, you should be able to acquire a developer key easily and you should do so). Having G1G1 use a subset of these features allows more extensive testing and thus helps us produce better software for deployment countries. So, contrary to your statement that it only seems to be a bother for people who want to help out with the OLPC project, having security enabled is one of the direct ways that people who want to help out *are in fact already doing so*. [And complaining about security when it gets in your way, within reason, is also directly helping out. =) ] G1G1 has always had slightly mixed goals, because N% of the people buying G1G1 machines are developers, and ~(100-N)% are parents or grandparents of small children. I believe N is well below 50%, based on devel@ traffic. Machines sent out via our developer program are always shipped out unsecured. We assume that G1G1 developers have the ability to request a developer key and disable security, and we recommend they do so; the security features are not meant for them. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
On Tue, Jun 3, 2008 at 12:43 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 03.06.2008, at 18:33, ffm wrote: On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Machines sent out via our developer program are always shipped out unsecured. Yet I've just recived two laptops via said program that had security enabled. Indeed. The machines distributed at LinuxTag last week also came w/o dev key - I think it is only the activation part that is disabled. My information may be out of date on the developer's program, since Adam has rebooted it recently and I don't think that developer's program machines actually come through OLPC any more. I should have said, used to be shipped out unsecured. Adam, are the new developer's program machines shipped direct, or do we have an opportunity to (at least) include a flyer explaining how to disable security on the machine? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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] G1G1: Security, to enable or disable...
On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Machines sent out via our developer program are always shipped out unsecured. Yet I've just recived two laptops via said program that had security enabled. -FFM ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
Developer program laptops are shipped out as US/International keyboards, English language, AK flag set, which means they do NOT need activation. They are permanently activated in the manufacturing data. The only thing they need to be a developer unit is a developer key. One more reason to add to Scott's list of why laptops are sent out to G1G1 'write protected' is so they are protected from non-signed images coming from malicious sources. If you don't use a developer's key to un protect the laptop, then you can only upgrade to OLPC signed builds. This is an important part of the bitfrost security that is implemented and working! FFM - if you really got two laptops from the developer's program that weren't activated, then could you put those details into an RT ticket and we'll debug it there. If there really are laptops going out that are un-activated that we don't know about, that will be a serious problem. The ONLY un-activated laptops are ones built for Peru, Mexico, and Uruguay. These are very specific SKUs and that include Spanish keyboards. Please open a ticket and let's figure that out. Thanks, Kim On Tue, Jun 3, 2008 at 1:07 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 12:43 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 03.06.2008, at 18:33, ffm wrote: On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Machines sent out via our developer program are always shipped out unsecured. Yet I've just recived two laptops via said program that had security enabled. Indeed. The machines distributed at LinuxTag last week also came w/o dev key - I think it is only the activation part that is disabled. My information may be out of date on the developer's program, since Adam has rebooted it recently and I don't think that developer's program machines actually come through OLPC any more. I should have said, used to be shipped out unsecured. Adam, are the new developer's program machines shipped direct, or do we have an opportunity to (at least) include a flyer explaining how to disable security on the machine? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] G1G1: Security, to enable or disable...
I continue to be uncomfortable that we are sending out restricted / locked-down machines without a clear need. The arguments made so far for this are 1. Getting G1G1 people to test security steps 2. Protecting G1G1 donors from installing anything but signed builds 3. Showing a pretty boot screen 3. represents a bug that should be fixed. Tying pretty boot to machine-lockdown is arbitrary. 2. assumes that this is the best result for G1G1 donors, which seems unlikely to me. Discovering how to update to anything but the most aggressively promoted builds is already a sign of tech savvy. This protection would still effectively be in place for the vast majority of users for whom it matters if we aggressively recommended to users (say, after a couple of days of use) that they get a developers key if they want full control of their machines for any reason. 1. is an interesting argument. As with 2, it would still hold if recipients were actively encouraged to get developers keys if they have any interest in having full control of their machines (indeed you could say that they we would have a much better test of the dev-key acquisition process, which currently works more clearly in large batches for countries than for individuals). SJ On Tue, Jun 3, 2008 at 9:46 PM, Kim Quirk [EMAIL PROTECTED] wrote: Developer program laptops are shipped out as US/International keyboards, English language, AK flag set, which means they do NOT need activation. They are permanently activated in the manufacturing data. The only thing they need to be a developer unit is a developer key. One more reason to add to Scott's list of why laptops are sent out to G1G1 'write protected' is so they are protected from non-signed images coming from malicious sources. If you don't use a developer's key to un protect the laptop, then you can only upgrade to OLPC signed builds. This is an important part of the bitfrost security that is implemented and working! FFM - if you really got two laptops from the developer's program that weren't activated, then could you put those details into an RT ticket and we'll debug it there. If there really are laptops going out that are un-activated that we don't know about, that will be a serious problem. The ONLY un-activated laptops are ones built for Peru, Mexico, and Uruguay. These are very specific SKUs and that include Spanish keyboards. Please open a ticket and let's figure that out. Thanks, Kim On Tue, Jun 3, 2008 at 1:07 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 12:43 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 03.06.2008, at 18:33, ffm wrote: On Tue, Jun 3, 2008 at 12:29 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Machines sent out via our developer program are always shipped out unsecured. Yet I've just recived two laptops via said program that had security enabled. Indeed. The machines distributed at LinuxTag last week also came w/o dev key - I think it is only the activation part that is disabled. My information may be out of date on the developer's program, since Adam has rebooted it recently and I don't think that developer's program machines actually come through OLPC any more. I should have said, used to be shipped out unsecured. Adam, are the new developer's program machines shipped direct, or do we have an opportunity to (at least) include a flyer explaining how to disable security on the machine? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ 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: [OLPC Security] G1G1: Security, to enable or disable...
Shipping G1G1 machines with NAND reflash locks enabled makes little sense to me. What good is protection against malicious reflash when any attacker who can perform a reflash has physical access to the device and has password-free root access in default configurations? Instead, the justification that I recall most strongly from when I last inquired about the purpose of enabling the NAND reflash lock on G1G1 machines is that it is primarily intended to reduce support costs by making it harder to test non-Released builds via reflash. I countered that the value of the extra testing we might receive would far outweigh the extra support costs that we might incur but, evidently, my argument was not decisive. Scott - were there other justifications given for the NAND reflash lock? I vaguely recall that you argued that, by default, OFW ought to be prohibited from writing unsigned data to the NAND on the grounds that bugs in the prohibited code paths might otherwise violate security goals of clients shipping passive-kill or active-kill technologies. Did I recall your justification correctly? Michael ___ 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 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: [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: [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 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: [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 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: [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: [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, 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: OLPC security project
I think this might be a very interesting topic. I'm unsure as to what has or has not been investigated though... should I concentrate my analysis more on D-Bus, Telepathy, or how the presence service implements these and the logical paths the system takes to get to the service? If I should focus more on the implementation, which files/directories should I look at? Thanks again! Jeremy Polychronis Ypodimatopoulos wrote: Our presence algorithms should be evaluated in terms of security (impersonation, dos, mim, etc). A list of vulnerabilities should be analyzed and solutions should be proposed. More details will follow if interested. p. Jeremy Flores wrote: Hi all, Does anyone know of any security-related projects that need to be worked on for OLPC? I am taking a computer and network security class, and I was thinking that Bitfrost would be an interesting topic for a final project we have. I poked around the wiki, but I couldn't find a security todo list. Thanks! Jeremy Flores [EMAIL PROTECTED] ___ 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
OLPC security project
Hi all, Does anyone know of any security-related projects that need to be worked on for OLPC? I am taking a computer and network security class, and I was thinking that Bitfrost would be an interesting topic for a final project we have. I poked around the wiki, but I couldn't find a security todo list. Thanks! Jeremy Flores [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC security project
Our presence algorithms should be evaluated in terms of security (impersonation, dos, mim, etc). A list of vulnerabilities should be analyzed and solutions should be proposed. More details will follow if interested. p. Jeremy Flores wrote: Hi all, Does anyone know of any security-related projects that need to be worked on for OLPC? I am taking a computer and network security class, and I was thinking that Bitfrost would be an interesting topic for a final project we have. I poked around the wiki, but I couldn't find a security todo list. Thanks! Jeremy Flores [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC security project
We just (in a somewhat terse manner) posted a status for the various Bitfrost components in the wiki (See http://wiki.laptop.org/go/Bitfrost#Current_Status). Perhaps you will find your inspiration there. -walter On Fri, Mar 28, 2008 at 10:37 AM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: Our presence algorithms should be evaluated in terms of security (impersonation, dos, mim, etc). A list of vulnerabilities should be analyzed and solutions should be proposed. More details will follow if interested. p. Jeremy Flores wrote: Hi all, Does anyone know of any security-related projects that need to be worked on for OLPC? I am taking a computer and network security class, and I was thinking that Bitfrost would be an interesting topic for a final project we have. I poked around the wiki, but I couldn't find a security todo list. Thanks! Jeremy Flores [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE:Subject: OLPC security project
He Jeremy, Here's one for you (school server security audit): http://dev.laptop.org/ticket/1506 A nessus scan seems like a good start but you may know better tools. I'm a volunteer so any suggestions from developers working on deployments would take higher priority. Thanks, Greg S -- Message: 5 Date: Fri, 28 Mar 2008 10:27:07 -0400 From: Jeremy Flores [EMAIL PROTECTED] Subject: OLPC security project To: devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi all, Does anyone know of any security-related projects that need to be worked on for OLPC? I am taking a computer and network security class, and I was thinking that Bitfrost would be an interesting topic for a final project we have. I poked around the wiki, but I couldn't find a security todo list. Thanks! Jeremy Flores [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] [sugar] secure /tmp and /var/tmp
I sympathize with Albert's point here: we should be no more incompatible than we have to be... Just because we have to break some things, doesn't mean we have to break everything. - Jim On Thu, 2007-11-08 at 10:42 -0500, Albert Cahalan wrote: On 11/8/07, Ivan Krstić [EMAIL PROTECTED] wrote: On Nov 7, 2007, at 9:09 PM, Albert Cahalan wrote: Using standard directories is not scribbling all over the filesystem! This anti-compatibility attitude needs to stop. It's really hurting OLPC, needlessly making the goals harder to achieve. Breaking compatibility is something to be done as a last resort, when no alterative will work. For better or for worse, compatibility has been broken, and on a level as fundamental as file access. If an application can't even access the user's files without being aware of the datastore, what good is it to pretend that providing small bits of backwards compatibility will make things substantially easier? One failure is no excuse to purposely fail in every way. Not every application even needs access to a user's files. The datastore has changed and apparantly will change. Perhaps it can someday be less awkward to deal with. In any case, yes, it is extra work and ugly code. You're affecting every porting effort; it must be easy to make that decision when it's somebody else's code base getting screwed with #ifdef everywhere. For us, $SAR/tmp lives in RAM and is severely limited (maybe to as little as 1MB per application). $SAR/instance is used for transient per-instance disk-backed storage. Since it's a given that work needs to be done to port applications to Sugar, it's a _good_ thing that a programmer is also confronted with the decision as to which of these two temporary directories to use. Enabling a wrapper for /tmp would have us make that decision for them, and as fellow Python programmers know: explicit is better than implicit, and in the face of ambiguity, refuse the temptation to guess. This is nothing new. It's been standard on SunOS for ages. The /tmp directory is in RAM, and /var/tmp is on disk. You are not so special that you need to break everything. AFAIK, this is even a common (normal?) setup on BSD. BTW, if you're going to keep calling it $SAR, then you'd better make that the real name of the variable. The long-term goal should be to support solid sandboxing of true all-over-the-filesystem software installs. This may need a unionfs filesystem so that files can be put everywhere without the dummy files needed for file-on-file bind mounts. Imagine if you could install any RPM, knowing that it had no way to corrupt your OS. That goal is not something I'm spending much time thinking about. The level of protection provided by Bitfrost is not something you can do without serious compatibility breaks with how things are done at present. If you don't solve it, people will just turn Bitfrost off. ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
