Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
> > As I said in my previous email, Bitfrost clearly states (correctly, in > my mind) that even justified belief that code originates from some known > individual implies no trust relationship with that code. Period. Use > isolation to make it safer to play with code and use signing to help > reduce attackers' abilities to lie to you about what code you're going > to be running. > If you take this to the extreme, then you would reset manually-granted bitfrost privileges on every activity update, and even remove the default "resume" behavior from the journal for instances of that activity (if it is not the same code, it cannot be trusted to handle to handle the same data without an explicit "resume with new version" choice by the user). I think new versions which are from the same source should get an implied trust level - the same trust as prior versions, which, in general, will be strictly limited by Bitfrost. I think that the fact that such "same source" may be the same corrupted source does not affect this. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
On Wed, Mar 26, 2008 at 10:05:19AM -0600, Jameson Chema Quinn wrote: > I disagree with #2. I disagree with both #1 and #2 and, as the current maintainer of Rainbow, that should tell you something. More bluntly, please experiment and please publish your work with a public solicitation of criticism. It's true that, these days, I lack the uninterrupted time for serious attacks on our really security hard problems (X, communications security, and making isolation available on other platforms come to mind), but I'll _make_ time for patch review, discussion, and writing on these topics. (Understand that, like any occasionally capricious maintainer, I may or may not like your work, may or may not demand changes in your work before I decide to merge it with mine, and probably won't agree with you about the Right Way Forward. However, don't let that stop you!) > partially if we think things through. Adding a hook so that activities with > P_IDENT can request signatures, without seeing the private key, is IMO safe > and simple enough to be worth doing if it helps us with activity updates. It's a certainly a place to start - in other words, it may be independently useful and it will certainly give us better understanding of the overall problem. Please try it. > Activities spread virally by sharing. Alicia codes a new activity V1 and > signs it, it starts to spread. Bad Bob replaces Alicia's sig with his own > and keeps spreading it. Now Bad Bob can add his malicious code to the > activity later, and all the people who got the activity downstream from him > will automatically update to the malicious version. As I said in my previous email, Bitfrost clearly states (correctly, in my mind) that even justified belief that code originates from some known individual implies no trust relationship with that code. Period. Use isolation to make it safer to play with code and use signing to help reduce attackers' abilities to lie to you about what code you're going to be running. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
Develop clearly needs to be aware of whatever solution we come up with for activity updates. This means that Develop has to be able to do the signing. Right now, bitfrost does not give out the private key to activities (correctly) and does not allow activities to request a signature for something (wrongly - there is a P_IDENT bitfrost privilege which should allow activities which have it to sign things). I raised this issue on IRC and got two responses. 1. neuralis/ ivan krstic was the security guy on the team and he has just left. Do not expect this to be fixed soon. 2. Do not try to fix this yourself, as security must be done right or not at all. (apologies for stripping the nuances) I disagree with #2. Security must not be done wrong, but it can be done partially if we think things through. Adding a hook so that activities with P_IDENT can request signatures, without seeing the private key, is IMO safe and simple enough to be worth doing if it helps us with activity updates. (More summary from IRC: the tricky, unresolved issue is key trust - does a given public key mean what we think it means? This is separate from key security. Let me give a scenario. Activities spread virally by sharing. Alicia codes a new activity V1 and signs it, it starts to spread. Bad Bob replaces Alicia's sig with his own and keeps spreading it. Now Bad Bob can add his malicious code to the activity later, and all the people who got the activity downstream from him will automatically update to the malicious version. To me this is not a problem, because Bob could have added his code to the activity in the first place. It just lets him be a little lazier. It is 100% equivalent if Bob had added some general-purpose trojan to the app immediately, so auto-update has not created any new vulnerabilities. Also, if there are two versions of the same activity floating around with different signatures, noticeable things will start to happen - either someone downstream from Bob will get an update from Alicia that will mysteriously fail to autoinstall, or vice versa.) On Wed, Mar 26, 2008 at 7:10 AM, Guillaume Desmottes < [EMAIL PROTECTED]> wrote: > Le mardi 25 mars 2008 à 16:02 -0400, Benjamin M. Schwartz a écrit : > > This works, and will work for the proposed case. For the future, I see > > file transfer as precisely the sort of thing that should be handled > > internally to Telepathy. Perhaps Telepathy should implement XEP-0234 > > (file transfer)[2] or even XEP-0214 (file sharing)[3]. > > > > We have a draft of spec for file transfer (but it will be probably > modified) and a Salut branch implementing it. So that's definitely > something that could be done at some point. > > >G. > > ___ > Sugar mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/sugar > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
Le mardi 25 mars 2008 à 16:02 -0400, Benjamin M. Schwartz a écrit : > This works, and will work for the proposed case. For the future, I see > file transfer as precisely the sort of thing that should be handled > internally to Telepathy. Perhaps Telepathy should implement XEP-0234 > (file transfer)[2] or even XEP-0214 (file sharing)[3]. > We have a draft of spec for file transfer (but it will be probably modified) and a Salut branch implementing it. So that's definitely something that could be done at some point. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
Eben, I've got more questions than answers for you, but perhaps my smaller questions will make the overall problem easier to analyze. Michael Questions: First, how will we discover that a code exchange is needed? Three straw-man options include: a) include adequate information in a presence notification or in a resource discovery URL [1] to permit us to calculate decide protocol compatibility [1]: http://lists.laptop.org/pipermail/devel/2008-February/011108.html b) add a new handshake to the "join a shared instance" protocol to establish this information. c) leave it up to the activity to figure out (perhaps with assistance from a system service or library) Next, let us assume that a code or data exchange is necessary in order to provide protocol compatibility. How do I figure out what bits are needed? How do I figure out where to go in order to get the requisite bits? I think it would be wise to add some indirection here so that people who are not in physical proximity can acquire the bits from low-cost sources when possible and to fall back on direct exchange of bits when necessary. Also so that we can extend the bit-acquiry software with new protocols as they become available. (For a first draft, we might as well copy Read's use of HTTP-over-Tubes, since it's already conveniently available to us.) NB: If we ever want to imagine running Sugar on platforms other than XOs, (or even between XOs running significantly different builds), then we'd better consider system-dependency issues up front. (We can ignore this question temporarily while doing feasibility studies on our own platform, but if this idea is going to rock the world like I want it to, then we need to think early on about giving the humans operating our technology access to information adequate to debug and work around incompatibilities between their respective systems.) After acquiring the bits, there's a small question of what to do with them. Do they go into the Journal as a new entry? Are they immediately unpacked alongside the user's other activities? If so, do they obscure older versions of the same activity? Should the older version be removed? I'm particularly concerned by Pippy-generated bundles here because they seem like they might be particularly subject to edit wars simply by being so easy to create and modify! (Should Pippy-generated bundles "stake claims" to their names in the fashion proposed in [2]?) [2]: http://dev.laptop.org/git?p=users/krstic/installer;a=tree; > Naturally, there are some security concerns, but those could be easily > addressed, They are far from "easily" addressed, but there's a good argument that they're _worth_ addressing because, in my opinion, easy and safe code sharing is one of the most attractive UI goals of our project! > I believe, with the usual signing mechanisms. Updates to > activities would only be transparent if the update was signed, etc. Information assurance mechanisms primarily deal with spoofing attacks and network hanky-panky. Isolation mechanisms are what we're using to make it generally safer to run code, regardless of whether we know where it came from. Both are necessary to make this "easy code sharing" policy more safe to pursue. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
