[OLPC Security] While we're on Cerebro, Telepathy, etc... Cerebro + bitfrost?

[Jameson "Chema" Quinn]

On Wed, Jun 11, 2008 at 3:08 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

> On 11.06.2008, at 03:37, Jameson Chema Quinn wrote:
>
>  Thus, there would be three kinds of activities:
>>
>> those with full network access, able to talk to arbitrary IP addresses
>> (browse is inescapably in this category);
>>
>> those with some kind of "telepathy-only" access, which would only let them
>> talk to IP addresses that correspond to a friend sharing the specific
>> activity instance (Chat might fit here; certainly, Write would);
>>
>> and those with no network permissions.
>>
>> The telepathy-only, middle security level would allow the last two "good"
>> use cases, while preventing the last two "bad" use cases. It could be
>> implemented by sugar giving them some kind of key, valid only for that
>> specific instance (and renewed when the instance is resumed) that they could
>> use to "unlock" access to a given IP. I understand that the middle security
>> level would not necessarily be perfect - a man-in-the-middle attack could
>> well subvert any gains, and, especially in early versions, it would be hard
>> to guarantee that any abstraction layer was 100% successful at keeping
>> malformed requests from getting some illicit control over a lower layer -
>> but it would drastically reduce the practicality of any large-scale
>> snoop-net or bot-net for your average shareable activity. Assuming that the
>> connection to friend X was compromised; an activity would still have to hope
>> it was started with an instance that had been shared with friend X in order
>> to leak any data.
>>
>
>
> Err, hasn't that been the plan all along? P_NETWORK is only given to
> activities needing full network access. It is independent of sharing. An
> activity wanting to share must use telepathy, period. Your "no network
> permissions" above case does not exist separately, it is the same as
> "telepathy-only".
>
> - Bert -
>


It is great to hear that this is not a new idea. Looking back at the
implementation speculation, m_stone's
http://cr.yp.to/unix/disablenetwork.html idea would, of course, not prevent
access to a service like Telepathy which is available over DBus. Still, from
my outsider perspective, it is not quite fair to say that it is "the plan
all along". Here's what I've seen of the plan: (the bitfrost spec, emphasis
mine):

"Each program's network utilization can be constrained in the following
ways:

   - * Boolean network on/off restriction*
   - token-bucketed bandwidth throttling with burst allowance
   - connection rate limiting
   - * packet destination restrictions by host name, IP and port(s)*
   - time-of-day restrictions on network use
   - data transfer limit by hour or day
   - server restriction (can bind and listen on a socket), Boolean and
   per-port

Reasonable default rate and transfer limits will be imposed on all
non-signed programs. If necessary, different policies can apply to mesh and
access point traffic. Additional restrictions might be added to this list as
we complete our evaluation of network policy requirements. "
Neither of the relevant points makes any reference to poking holes in this
"firewall" for collaboration.

Also, there are some features in Telepathy/whatever that would be needed to
give it security characteristics

In order for an abstraction layer to have security characteristics, it would
probably need to:
-be in a separate process, communicating through DBus; done.
-Not allow an activity to do anything by itself that would be visible on the
network, except for maybe announcing its (un)willingness to share. The
network-visible name of the activity would be set by Glucose, sharing
partners would be set from Glucose (including any search, invitations, and
responses, as well as handling resuming shared instances). It is not my
impressiong that Telepathy worries about this kind of security; if I am
wrong, such thinking should certainly be documented.

...

I opened this thread to understand how people felt about this idea. If Bert
is right, and this is the unstated general plan, then great! I am not just
saying "you guys oughtta", I can start to look at this issue and post much
more specific bugs to continue the conversation on an implementation level.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080611/e65a03c9/attachment-0001.htm