Re: Terminals
On Fri, Aug 01, 2008 at 07:32:11PM -0400, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | Is it possible that we could | simply have a P_ROOT permission as well, or does that blow Bitfrost out of | the water? 1. According to my reading of http://dev.laptop.org/git?p=users/mstone/security;a=blob;f=bitfrost.txt;h=96f4997602d817abf7be90a00bf68b3a79a73005;hb=HEAD#l442 Bitfrost is not compatible with a P_ROOT permission. 2. Direct manipulations of the trusted code base by the distribution chain are also supported: http://dev.laptop.org/git?p=users/mstone/security;a=blob;f=bitfrost.txt;h=96f4997602d817abf7be90a00bf68b3a79a73005;hb=HEAD#l450 3. I believe that the existing 'olpc-update', 'yum+gpg', and 'olpc-configure+rpms' mechanisms already satisfy the demands of (2). We need an _interface_ that allows users to specify which Activities can run with which permissions. Correct. To build that, we need Rainbow to support different running different Activities with different permissions. Rainbow has supported placing activities into different groups based on the contents of a 'permissions.info' file for months. See commit 58c164f2 which shipped in rainbow-0.7.11 on March 25, 2008. (The work leading up to that commit was actually available in commit bd26557f from November 13, 2007 but was not merged until March because of various code freezes that lasted somewhat longer than they should.) As you can see, the present security difficulties stem from the lack of effort spent on recording user intentions about what permissions should be applied to what activities. Signatures do absolutely nothing to address this problem -- they only permit an as-yet undesigned system interpreter to check whether the authors W of claim X about blob Y knew secret Z. These assertions yield no new power because the Bitfrost security model asserts that trusting that author W wrote blob Y implies no trust in blob Y itself. It's a good reason to display hints about blob Y, to display blob Y nearby to blobs Y_1, Y_2, etc. also by author W, but it is _NOT_ sufficient to grant Y permissions in the initial default-deny configuration proposed by Bitfrost. It is probably appropriate, here, to reiterate my third claim above -- namely, that deployment-team's desire to add code directly to the TCB is _already covered_ by other mechanisms unrelated to activity installation. To build that, we need Activities to be identified by a unique secure token. To build that, we need a new bundle format. No new bundle format is needed to track activities according to non-spoofable tokens. All that is needed is to teach the software making authorization decisions (Sugar) to use the correct token. Regards, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
As you can see, the present security difficulties stem from the lack of effort spent on recording user intentions about what permissions should be applied to what activities. Signatures do absolutely nothing to address this problem -- they only permit an as-yet undesigned system interpreter to check whether the authors W of claim X about blob Y knew secret Z. This is literally true, of course, but I think that it is a misunderstanding of what Benjamin said. The signatures stumbling block is actually the hashes stumbling block - that is, the ability to refer to blob Y in a way that is stable across installation/repacking, .pyc compilation, etc, but secure against changes. These assertions yield no new power because the Bitfrost security model asserts that trusting that author W wrote blob Y implies no trust in blob Y itself. It's a good reason to display hints about blob Y, to display blob Y nearby to blobs Y_1, Y_2, etc. also by author W, but it is _NOT_ sufficient to grant Y permissions in the initial default-deny configuration proposed by Bitfrost. This is also close to true, but not entirely. In general, we will not trust code simply because it comes from a given author. However, Bitfrost is not quite as categorical as you imply. I think that the code/user distinction is primarily a *distinction* between trust in a user and trust in their code, not a firm declaration that the latter is impossible without explicit intervention. Here's the relevant paragraph: *Unfortunately, software received through a friend or acquaintance is completely untrusted code, because there's no trust mapping between people and software: trusting a friend isn't, and cannot be, the same as trusting code coming from that friend. The friend's machine might be taken over, and may be attempting to send malicious code to all her friends, or the friend might be trying to execute a prank, or he might have written—either out of ignorance or malice -- software that is sometimes malicious.* No new bundle format is needed to track activities according to non-spoofable tokens. All that is needed is to teach the software making authorization decisions (Sugar) to use the correct token. I disagree - for stronger security, a new bundle format which includes hashes is, if not 100% necessary, at least clearly desirable. However, you are right that we can do much better without this, and I am currently working on a patch which does that - for 5657. Jameson ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On Sat, Aug 02, 2008 at 03:03:24PM -0600, Jameson Chema Quinn wrote: As you can see, the present security difficulties stem from the lack of effort spent on recording user intentions about what permissions should be applied to what activities. Signatures do absolutely nothing to address this problem -- they only permit an as-yet undesigned system interpreter to check whether the authors W of claim X about blob Y knew secret Z. This is literally true, of course, but I think that it is a misunderstanding of what Benjamin said. The signatures stumbling block is actually the hashes stumbling block - that is, the ability to refer to blob Y in a way that is stable across installation/repacking, .pyc compilation, etc, but secure against changes. 1) Hashing is unnecessary. The raw contents of the activity's directory on the filesystem are the best identification of that activity. Naturally, hashing such as is provided by olpc-contents can be used for efficiency purposes; however, this hashing (really manifest construction) can and should be performed directly on the activity's unpacked files at installation before the activity is run. These assertions yield no new power because the Bitfrost security model asserts that trusting that author W wrote blob Y implies no trust in blob Y itself. It's a good reason to display hints about blob Y, to display blob Y nearby to blobs Y_1, Y_2, etc. also by author W, but it is _NOT_ sufficient to grant Y permissions in the initial default-deny configuration proposed by Bitfrost. This is also close to true, but not entirely. In general, we will not trust code simply because it comes from a given author. However, Bitfrost is not quite as categorical as you imply. I think that the code/user distinction is primarily a *distinction* between trust in a user and trust in their code, not a firm declaration that the latter is impossible without explicit intervention. Here's the relevant paragraph: *Unfortunately, software received through a friend or acquaintance is completely untrusted code, because there's no trust mapping between people and software: trusting a friend isn't, and cannot be, the same as trusting code coming from that friend. The friend's machine might be taken over, and may be attempting to send malicious code to all her friends, or the friend might be trying to execute a prank, And the relevant line is the final one; or he might have written—either out of ignorance or malice -- software that is sometimes malicious. which clearly considers the potential for friends to intentionally ship you malicious code. (I'm absolutely willing to grant that better identity mechanisms would do a world of good to improve the actual security provided by the system; however, I continue to insist that they are at best tangential to the fundamental problem which is, as stated above, the lack of a suitable _user interface_ for recording user-generated permission grants.) No new bundle format is needed to track activities according to non-spoofable tokens. All that is needed is to teach the software making authorization decisions (Sugar) to use the correct token. I disagree - for stronger security, a new bundle format which includes hashes is, if not 100% necessary, at least clearly desirable. However, you are right that we can do much better without this, and I am currently working on a patch which does that - for 5657. As above, hashes can be computed on the unpacked activity bundles. No modification to the bundle format is necessary; moreover, why would you ever rely on the correctness of a manifest supplied by the bundle itself? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
As above, hashes can be computed on the unpacked activity bundles. No modification to the bundle format is necessary; moreover, why would you ever rely on the correctness of a manifest supplied by the bundle itself? The current manifest format hashes everything in a directory. That includes python compiled files (arguably correct, but also arguably a separate issue); any signatures or subfiles of signatures (manifests and hashes) which may be included in the future; git-related invisible files which may be on a developer's machine; and the dist/ directory, likewise. This could be a problem. A smart bundle format would, I argue, at a minimum exempt signatures and cryptographic manifest (not MANIFEST, but HASHES) from being hashed. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
Look, there is no reason to care about hashes. What is the fear here, that the jffs2 filesystem will fail? We have pathnames. Permissions are granted by the user. The only exception is when the OS is initially installed, or when the whole OS is upgraded. Permissions are tied to an inode. Since the kernel enforces that directories may not have hard links, one may also tie permissions to a directory. It'd be nice to have a way for activities to specify reasons to grant various permissions. This isn't a requirement. It'd be nice to to have a way for activities to specify permissions that are of no use (and thus should not be offered in the UI). This is not a requirement. Signatures and hashes are complexity. Complexity tends to be the enemy of security. The answer is really simple: every activity, no matter where it comes from (claiming to be an upgrade or not), gets sandboxed by default. Users grant permissions as desired. Bitfrost sure is compatible with P_ROOT. Of course any such permission would implicitly grant all others; such is life. There certainly should be a way to specify that setuid is to be respected, that su should be allowed, that UID should be 0, that the user's real home directory should be used, or that various capability bits should be enabled. The more dangerous items might best be handled via commands to be run at the Linux console, ensuring that nobody can hit them with random mouse clicking. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On 01.08.2008, at 04:29, [EMAIL PROTECTED] wrote: On Thu, 31 Jul 2008, Walter Bender wrote: Maybe the console is enough? if the console font has been changed to something more readable it can be used. Still wondering why Albert's font has not been adopted. Every time I olpc-update I'm reminded of the terrible standard font in the console, and I type ~oltabwtabwtabreturn which executes ~olpc/whiteonblack/whiteonblack installing the 15x30 font and reversing the video ... http://dev.laptop.org/~bert/whiteonblack.tar.gz - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On Fri, Aug 01, 2008 at 11:23:49AM +0200, Bert Freudenberg wrote: http://dev.laptop.org/~bert/whiteonblack.tar.gz +1 Works for me. But. Odd that it is slower than an xterm for displaying a ps ax ... 0.517s on 703 in the xterm, 3.068s in the text console ... why is it six times slower? (The xterm being compared was xterm -fa DejaVu LGC Sans Mono -fs 9 +sb -bg black -fg white started within a Terminal activity. Tested on a C2, which was idle.) Over to Alt/F2, the old font gives 1.359s for the text console. Still, this default font is slower than the xterm. It must be due to the output device ... ssh to the C2, ps ax takes 0.073s. Not exactly a rock solid test ... does anyone else see similar? -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On 01.08.2008, at 14:43, James Cameron wrote: On Fri, Aug 01, 2008 at 11:23:49AM +0200, Bert Freudenberg wrote: http://dev.laptop.org/~bert/whiteonblack.tar.gz +1 Works for me. But. Odd that it is slower than an xterm for displaying a ps ax ... 0.517s on 703 in the xterm, 3.068s in the text console ... why is it six times slower? (The xterm being compared was xterm -fa DejaVu LGC Sans Mono -fs 9 +sb -bg black -fg white started within a Terminal activity. Tested on a C2, which was idle.) Over to Alt/F2, the old font gives 1.359s for the text console. Still, this default font is slower than the xterm. It must be due to the output device ... ssh to the C2, ps ax takes 0.073s. Not exactly a rock solid test ... does anyone else see similar? Yes, the console feels rather slow. Guess the kernel is not using optimal blitting for scrolling (the X server is accelerated even). But then, I don't know how displaying/scrolling the console really works, hence, not pointing fingers ... - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On 1 Aug 2008, at 03:25, Walter Bender wrote: Curious as to what occasions need root access within X Windows? Maybe the console is enough? -walter I don't think I've used the console in months, nice to know it's there in an emergency, but it was problematic to use for normal admin tasks for two reasons: 1) The keyboard map does not match the machines actual keyboard, so trying to remember US key layout on a Spanish keypad is a nightmare :-) Anyone know any tricks to correct that? 2) Often the olpc related scripts I'd be trying to use would have some hooks into X, and other environment variables. Without a lot of env hacking/guessing they would just bomb out in console. On Thu, Jul 31, 2008 at 9:38 PM, Michael Stone [EMAIL PROTECTED] wrote: One of our present security difficulties is that the Terminal activity is not isolated. It is de-isolated so that it can serve the dual role of root terminal and 'general exploration' terminal. Perhaps reviving the Quake Terminal for the root-terminal role and isolating the Terminal activity proper would be a nice way to solve half of our security issue? --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
The keyboard issue is simply a matter of having the correct console keyboard map files installed. The one for Spanish is attached. Not sure what the current plan is for inclusion of these files (Dennis?). It should be installed in /lib/kbd/keymaps/i386/qwerty Regarding your second point, this is really what I was asking: what dependencies do we have for Sugar/X in normal admin tasks that require root? thanks. -walter On Fri, Aug 1, 2008 at 9:45 AM, Gary C Martin [EMAIL PROTECTED] wrote: On 1 Aug 2008, at 03:25, Walter Bender wrote: Curious as to what occasions need root access within X Windows? Maybe the console is enough? -walter I don't think I've used the console in months, nice to know it's there in an emergency, but it was problematic to use for normal admin tasks for two reasons: 1) The keyboard map does not match the machines actual keyboard, so trying to remember US key layout on a Spanish keypad is a nightmare :-) Anyone know any tricks to correct that? 2) Often the olpc related scripts I'd be trying to use would have some hooks into X, and other environment variables. Without a lot of env hacking/guessing they would just bomb out in console. On Thu, Jul 31, 2008 at 9:38 PM, Michael Stone [EMAIL PROTECTED] wrote: One of our present security difficulties is that the Terminal activity is not isolated. It is de-isolated so that it can serve the dual role of root terminal and 'general exploration' terminal. Perhaps reviving the Quake Terminal for the root-terminal role and isolating the Terminal activity proper would be a nice way to solve half of our security issue? --Gary es.map Description: application/extension-map ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On Fri, Aug 01, 2008 at 02:45:38PM +0100, Gary C Martin wrote: On 1 Aug 2008, at 03:25, Walter Bender wrote: Curious as to what occasions need root access within X Windows? Maybe the console is enough? That would work nicely for me, though it will work much less well for people who desire the ability to display non-Latin text. 1) The keyboard map does not match the machines actual keyboard, so trying to remember US key layout on a Spanish keypad is a nightmare :-) Anyone know any tricks to correct that? loadkeys us loadkeys es etc. (There may be errors in the console keyboard maps but we fix them as we find them.) 2) Often the olpc related scripts I'd be trying to use would have some hooks into X, and other environment variables. Without a lot of env hacking/guessing they would just bomb out in console. export DISPLAY=:0 export XAUTHORITY=/home/olpc/.Xauthority # may have moved. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On Fri, Aug 01, 2008 at 12:08:25PM -0400, Michael Stone wrote: On Fri, Aug 01, 2008 at 02:45:38PM +0100, Gary C Martin wrote: 2) Often the olpc related scripts I'd be trying to use would have some hooks into X, and other environment variables. Without a lot of env hacking/guessing they would just bomb out in console. export DISPLAY=:0 export XAUTHORITY=/home/olpc/.Xauthority # may have moved. DBUS_SESSION_BUS_ADDRESS too, depending on the script: http://dev.laptop.org/git?p=users/phil/support-scripts;a=commitdiff;h=c2b508de1524ae46975af290bd4cff8db5f73dd1 Michael Martin pgpjME27qUFWc.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On Fri, 1 Aug 2008, Gary C Martin wrote: On 1 Aug 2008, at 03:25, Walter Bender wrote: Curious as to what occasions need root access within X Windows? Maybe the console is enough? -walter I don't think I've used the console in months, nice to know it's there in an emergency, but it was problematic to use for normal admin tasks for two reasons: 1) The keyboard map does not match the machines actual keyboard, so trying to remember US key layout on a Spanish keypad is a nightmare :-) Anyone know any tricks to correct that? 2) Often the olpc related scripts I'd be trying to use would have some hooks into X, and other environment variables. Without a lot of env hacking/guessing they would just bomb out in console. numerous 'special keys' don't work at the console, including adjusting the screen brightness. David Lang On Thu, Jul 31, 2008 at 9:38 PM, Michael Stone [EMAIL PROTECTED] wrote: One of our present security difficulties is that the Terminal activity is not isolated. It is de-isolated so that it can serve the dual role of root terminal and 'general exploration' terminal. Perhaps reviving the Quake Terminal for the root-terminal role and isolating the Terminal activity proper would be a nice way to solve half of our security issue? --Gary ___ 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: Terminals
On Fri, Aug 01, 2008 at 11:03:39AM -0700, [EMAIL PROTECTED] wrote: numerous 'special keys' don't work at the console, including adjusting the screen brightness. To get this to work we would have to push olpc-specific drivers into the kernel, correct? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
erik wrote: On Fri, Aug 01, 2008 at 11:03:39AM -0700, [EMAIL PROTECTED] wrote: numerous 'special keys' don't work at the console, including adjusting the screen brightness. To get this to work we would have to push olpc-specific drivers into the kernel, correct? not necessarily. the keys can be monitored and acted on by a daemon of some sort. (but asking people to use the console with any regularity sure feels like a copout. To enter shell commands, first type 'ctrl-alt-networkview' just seems wrong.) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
Why does it matter that you cannot adjust the screen brightness from the console using the special keys? You can adjust it from Sugar without root access. The idea was to understand what limits we'd face using the console for root access instead of a special terminal activity. What are the Sugar/X Window actions that require root access? -walter On Fri, Aug 1, 2008 at 2:05 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2008 at 11:03:39AM -0700, [EMAIL PROTECTED] wrote: numerous 'special keys' don't work at the console, including adjusting the screen brightness. To get this to work we would have to push olpc-specific drivers into the kernel, correct? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bender wrote: | What are the Sugar/X Window actions that require root | access? This discussion is becoming a little confusing. The problem is not just root access. There are three accounts in play here: root, olpc, and 10005 (an arbitrary isolated instance uid generated by Rainbow). An isolated Terminal runs as 10005. It can: run any binary in the major world-readable directories (/usr/bin/*, etc.), spawn additional X applications in additional windows, provided those X applications are happy to run as user 10005. It cannot modify user settings with sugar-control-panel, read arbitrary items from the Datastore, read or write /home/olpc, or start new Activity instances. A de-isolated Terminal runs as olpc. It can: do anything that the olpc user can do, including use su to start a session as root, run any X program as olpc or root, modify settings with sugar-control-panel, launch new Activity instances, etc. A console session starts as root. It can: install RPMs, mess with stuff in /sys, and otherwise do anything whatsoever on the system. HOWEVER, it is currently nearly impossible to use this console to launch activities, run X programs, modify settings with sugar-control-panel, and otherwise mess with the running Sugar instance. This is mostly because the shell does not contain the correct environment variables to connect with the X display and D-Bus bus. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiTXqUACgkQUJT6e6HFtqTOjwCfXYvrQxCp/pPiI765U5rvvrVd w7YAn127vjO5xgNpAQiAzpvo4CDmt4qQ =rymY -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
Why does it matter that you cannot adjust the screen brightness from the console using the special keys? You can adjust it from Sugar without root access. The idea was to understand what limits we'd face using the console for root access instead of a special terminal activity. What are the Sugar/X Window actions that require root access? It doesn't matter if you have to abandon Sugar to do system administration or to recover from a problem? Walter, I'm shocked; I would've expected you to be arguing on the other side: Sugar should be the preferred environment. That we shouldn't be kicking people out of Sugar, particularly when their system is fragile and in need of diagnosis, repair, or upgrade. We should keep them in the environment they know and understand, where the Frame works, the controls work, the tabs work the same way, the keyboard keys all do the same things. It was hard for the Support Gang to explain to people how to become root so they could diagnose or fix something they reported as a problem (like a full filesystem, a USB key that didn't work, ...). OLPC was also changing the way you become root (su versus sudo) in different software releases, based on Fedora changes. We hashed all this out in January, and the Terminal got a new # button at the top, which injects the right command to make you root. There's no such button in the console. If we push people back to the console, the support load increases. It's easier to get them to run the Terminal applic...uh, activity, and press the root button, and type this command. Also, in Terminal, cut and paste works to send us back diagnostic results via Browse. The owners of free software based machines also need the ability to inspect and revise the free software in those machines -- or it isn't free as in freedom. Legally, OLPC can push that ability out to the very corners of the system (e.g. You can't do that in Sugar.). But morally and philosophically, we ought to be pulling it right into the heart of the system (Of course you can, and it's so easy; here, let me show you!). Let's not lose sight of what's going on here. The whole reason we are having this discussion at all is because of OLPC's security model (Bitfrost). If the security model doesn't permit integrated, interactive root access that lets people diagnose, repair, investigate, and alter their systems, there's something wrong with the security model -- not something wrong with root access. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On Fri, Aug 1, 2008 at 4:07 PM, John Gilmore [EMAIL PROTECTED] wrote: Why does it matter that you cannot adjust the screen brightness from the console using the special keys? You can adjust it from Sugar without root access. The idea was to understand what limits we'd face using the console for root access instead of a special terminal activity. What are the Sugar/X Window actions that require root access? It doesn't matter if you have to abandon Sugar to do system administration or to recover from a problem? Walter, I'm shocked; I would've expected you to be arguing on the other side: Sugar should be the preferred environment. That we shouldn't be kicking people out of Sugar, particularly when their system is fragile and in need of diagnosis, repair, or upgrade. We should keep them in the environment they know and understand, where the Frame works, the controls work, the tabs work the same way, the keyboard keys all do the same things. It was hard for the Support Gang to explain to people how to become root so they could diagnose or fix something they reported as a problem (like a full filesystem, a USB key that didn't work, ...). OLPC was also changing the way you become root (su versus sudo) in different software releases, based on Fedora changes. We hashed all this out in January, and the Terminal got a new # button at the top, which injects the right command to make you root. There's no such button in the console. If we push people back to the console, the support load increases. It's easier to get them to run the Terminal applic...uh, activity, and press the root button, and type this command. Also, in Terminal, cut and paste works to send us back diagnostic results via Browse. The owners of free software based machines also need the ability to inspect and revise the free software in those machines -- or it isn't free as in freedom. Legally, OLPC can push that ability out to the very corners of the system (e.g. You can't do that in Sugar.). But morally and philosophically, we ought to be pulling it right into the heart of the system (Of course you can, and it's so easy; here, let me show you!). I agree with everything said above. Let's not lose sight of what's going on here. The whole reason we are having this discussion at all is because of OLPC's security model (Bitfrost). If the security model doesn't permit integrated, interactive root access that lets people diagnose, repair, investigate, and alter their systems, there's something wrong with the security model -- not something wrong with root access. And I wonder if it could really be so simple. Is it possible that we could simply have a P_ROOT permission as well, or does that blow Bitfrost out of the water? In a way I'd hope not, since the whole point is that the desire for root is requested/advertised, and therefore can (eventually) be denied; P_ROOT clearly wouldn't be granted within the default permissions either, once we have them. I write this assuming that this might not help matters at all...it could be too lenient. But perhaps we could offer the P_ROOT only to activities which a) request it and b) are signed by some signing authority (could be us, could be a country, etc.), where the security section of the control panel offers a place to designate trusted signing authorities. I'm no security guru, though, which I willingly admit! Is anything I've mentioned worth even considering? Clearly it's not as secure, and there are ways that someone can instruct a kid to go to the CP, enter a new authority, install an evil app, etc. But There's a tradeoff here much like the memory/speed tradeoff we battle with every day we hack at code...you can only improve some algorithms so much, and beyond that you have to choose what to optimize for. - Eben John ___ 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: Terminals
2008/8/1 Eben Eliason [EMAIL PROTECTED] On Fri, Aug 1, 2008 at 4:07 PM, John Gilmore [EMAIL PROTECTED] wrote: Why does it matter that you cannot adjust the screen brightness from the console using the special keys? You can adjust it from Sugar without root access. The idea was to understand what limits we'd face using the console for root access instead of a special terminal activity. What are the Sugar/X Window actions that require root access? It doesn't matter if you have to abandon Sugar to do system administration or to recover from a problem? Walter, I'm shocked; I would've expected you to be arguing on the other side: Sugar should be the preferred environment. That we shouldn't be kicking people out of Sugar, particularly when their system is fragile and in need of diagnosis, repair, or upgrade. We should keep them in the environment they know and understand, where the Frame works, the controls work, the tabs work the same way, the keyboard keys all do the same things. It was hard for the Support Gang to explain to people how to become root so they could diagnose or fix something they reported as a problem (like a full filesystem, a USB key that didn't work, ...). OLPC was also changing the way you become root (su versus sudo) in different software releases, based on Fedora changes. We hashed all this out in January, and the Terminal got a new # button at the top, which injects the right command to make you root. There's no such button in the console. If we push people back to the console, the support load increases. It's easier to get them to run the Terminal applic...uh, activity, and press the root button, and type this command. Also, in Terminal, cut and paste works to send us back diagnostic results via Browse. The owners of free software based machines also need the ability to inspect and revise the free software in those machines -- or it isn't free as in freedom. Legally, OLPC can push that ability out to the very corners of the system (e.g. You can't do that in Sugar.). But morally and philosophically, we ought to be pulling it right into the heart of the system (Of course you can, and it's so easy; here, let me show you!). I agree with everything said above. Let's not lose sight of what's going on here. The whole reason we are having this discussion at all is because of OLPC's security model (Bitfrost). If the security model doesn't permit integrated, interactive root access that lets people diagnose, repair, investigate, and alter their systems, there's something wrong with the security model -- not something wrong with root access. And I wonder if it could really be so simple. Is it possible that we could simply have a P_ROOT permission as well, or does that blow Bitfrost out of the water? In a way I'd hope not, since the whole point is that the desire for root is requested/advertised, and therefore can (eventually) be denied; P_ROOT clearly wouldn't be granted within the default permissions either, once we have them. Coincidentally, I have a patch which does just that! See my thread on [EMAIL PROTECTED] OK, I guess I should copy it to devel@ and security@ while I'm at it. I write this assuming that this might not help matters at all...it could be too lenient. But perhaps we could offer the P_ROOT only to activities which a) request it and b) are signed by some signing authority (could be us, could be a country, etc.), where the security section of the control panel offers a place to designate trusted signing authorities. I'm no security guru, though, which I willingly admit! Is anything I've mentioned worth even considering? Once we have activity signatures, we can talk about this more concretely. I expect that, for general bitfrost permissions, there will be a bitfrost control panel that allows you to grant certain permissions to a specific (hashed version of an) activity; or to delegate the power to grant certain permissions to other signers (such as the author of an activity, so that updates get same permissions). I think that it is reasonable to put additional restrictions on the P_ROOT permission: perhaps it can ONLY be granted to activities installed at build time OR signed by current XO? (Then, to change the version of your terminal, you'd either have to do a full update to a new build, or touch the new version of terminal activity with Develop to make it yours). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On Fri, 1 Aug 2008, Walter Bender wrote: Why does it matter that you cannot adjust the screen brightness from the console using the special keys? You can adjust it from Sugar without root access. so you switch from sugar to the console, something changes (including noticing that the font needs more light to be readable), so you then have to change back to Sugar to change the setting, then go back to the console to try and do the work. this seems like a very user hostile approach. the fact that you can't cut and paste to or from the console is also a problem (try and enter the command to get a developer key by switching back and forth from Sugar (where browse is displaying it) to the console (where you need to type it) David Lang The idea was to understand what limits we'd face using the console for root access instead of a special terminal activity. What are the Sugar/X Window actions that require root access? -walter On Fri, Aug 1, 2008 at 2:05 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2008 at 11:03:39AM -0700, [EMAIL PROTECTED] wrote: numerous 'special keys' don't work at the console, including adjusting the screen brightness. To get this to work we would have to push olpc-specific drivers into the kernel, correct? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | Is it possible that we could | simply have a P_ROOT permission as well, or does that blow Bitfrost out of | the water? It's called P_SF_RUN or P_SF_CORE, depending on what you mean by root. In other words, yes, this was planned. We need an interface that allows users to specify which Activities can run with which permissions. To build that, we need Rainbow to support different running different Activities with different permissions. To build that, we need Activities to be identified by a unique secure token. To build that, we need a new bundle format. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiTnPsACgkQUJT6e6HFtqSMZQCfcMSVCMON075fA/uuHedDAvas UwwAnAgj38pi0eRjVKsjzsiVV8PMSnkZ =E5dh -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On 1 Aug 2008, at 14:54, Walter Bender wrote:
The keyboard issue is simply a matter of having the correct console
keyboard map files installed. The one for Spanish is attached. Not
sure what the current plan is for inclusion of these files (Dennis?).
It should be installed in /lib/kbd/keymaps/i386/qwerty
Thanks Walter. From Michael's email (thanks too), it looks like the
maps are installed (current Joyride build) already, and a loadkeys es
from the console gets a fair few more of the keys correct. Is this
something worth improving as the map could do with quite a bunch of
corrections? Here's a quick list of miss-matches I noted:
` (shift 3) generates a floating dot of some kind
{ (shift [) generates a strange star like character (not *)
[ generates a +
] generates a ç (c with a 5 shape like accent below)
} (shift ]) generates an uppercase Ç (as above)
+ generates some hidden accent modifier
* generates some hidden accent modifier
~ generates {
^ (alt-gr 5) has no visible effect
\ (alt-gr 7) generates }
º generates [
has no visible effect
has no visible effect
(please let me know if there is a formal place/format I should report
these to if the change is worth making).
The console still feels like a fallback tool in the case of
emergencies (I'm glad to have it there), but Terminal is now a much
more functional (and integrated) interface as noted in a number of
other emails.
--Gary
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Terminals
One of our present security difficulties is that the Terminal activity is not isolated. It is de-isolated so that it can serve the dual role of root terminal and 'general exploration' terminal. Perhaps reviving the Quake Terminal for the root-terminal role and isolating the Terminal activity proper would be a nice way to solve half of our security issue? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
Curious as to what occasions need root access within X Windows? Maybe the console is enough? -walter On Thu, Jul 31, 2008 at 9:38 PM, Michael Stone [EMAIL PROTECTED] wrote: One of our present security difficulties is that the Terminal activity is not isolated. It is de-isolated so that it can serve the dual role of root terminal and 'general exploration' terminal. Perhaps reviving the Quake Terminal for the root-terminal role and isolating the Terminal activity proper would be a nice way to solve half of our security issue? Michael ___ 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: Terminals
On Thu, 31 Jul 2008, Walter Bender wrote: Curious as to what occasions need root access within X Windows? Maybe the console is enough? if the console font has been changed to something more readable it can be used. there end up being a surprising number of things where advanced users end up needing to tweak the system. not having to switch out of X to do it can be handy (this matters a bit less then usual currently due to forcing everything to be full screen) David Lang -walter On Thu, Jul 31, 2008 at 9:38 PM, Michael Stone [EMAIL PROTECTED] wrote: One of our present security difficulties is that the Terminal activity is not isolated. It is de-isolated so that it can serve the dual role of root terminal and 'general exploration' terminal. Perhaps reviving the Quake Terminal for the root-terminal role and isolating the Terminal activity proper would be a nice way to solve half of our security issue? Michael ___ 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: Terminals
Note that I am currently working on a (somewhat large) patch which will not turn off isolation for anything outside share/... (that is, the activities in ~/Activities will all be isolated). This will close the gigantic security hole where anything named Terminal or Journal was not isolated. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
michael wrote: One of our present security difficulties is that the Terminal activity is not isolated. It is de-isolated so that it can serve the dual role of root terminal and 'general exploration' terminal. Perhaps reviving the Quake Terminal for the root-terminal role and isolating the Terminal activity proper would be a nice way to solve half of our security issue? a) what's the Quake terminal, and b) how does it help? (if it's an activity, it would just move the problem, so i'm guessing it's not?) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
On Thu, Jul 31, 2008 at 11:08:17PM -0400, [EMAIL PROTECTED] wrote: michael wrote: One of our present security difficulties is that the Terminal activity is not isolated. It is de-isolated so that it can serve the dual role of root terminal and 'general exploration' terminal. Perhaps reviving the Quake Terminal for the root-terminal role and isolating the Terminal activity proper would be a nice way to solve half of our security issue? a) what's the Quake terminal A vte-based widget run from within the Sugar shell: http://xo.cutup.org/quake-terminal.txt b) how does it help? It runs within the Sugar shell, so it's privileged. paul Martin pgpGEwSipq58T.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Terminals
Michael Stone writes: One of our present security difficulties is that the Terminal activity is not isolated. It is de-isolated so that it can serve the dual role of root terminal and 'general exploration' terminal. Perhaps reviving the Quake Terminal for the root-terminal role and isolating the Terminal activity proper would be a nice way to solve half of our security issue? No. First of all, that would force usage of the root account to get to the olpc account. There is little reason to want a random user, but plenty of reason to want both olpc and root. Second of all, the ability to de-isolate an arbitrary activity is important. Isolation needs to be under the user's control. Except to prevent a user from locking himself out by isolating the de-isolation tool, no activity should be specially known to Bitfrost or Sugar. Isolation is righfully a user choice. It's OK to make isolation easier though, to avoid accidents. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
