Terminals

[Michael Stone]

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?