Terminals

[Jameson "Chema" Quinn]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080802/9cb381ae/attachment.html>