> > 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