On Thu, 2011-05-26 at 20:38 +0200, Pavel Machek wrote: > On Thu 2011-05-26 14:11:54, David Safford wrote: > > On Thu, 2011-05-26 at 09:34 -0700, Casey Schaufler wrote: > > > On 5/25/2011 11:08 PM, Pavel Machek wrote: > > > > ... > > > > Fourthly, is it likely to find its way to the next cellphone I buy, > > > > and will it prevent me from rooting it? > > > > > > That will of course depend on the phone vendor. You are certainly > > > going to be able to vote with your checkbook (digital wallet?) but > > > odds are pretty good that should EVM prove effective it will be > > > ubiquitous within the next five years on embedded devices. > > Hmm. But maybe it is more effective to vote with NAKs, now? It does > not seem to have any non-evil uses. > > Phone vendors will play nasty tricks on us, but... why make it easy > for them? > > > um, not quite the right threat model... > > > > Rooting is normally done through an exploit of the loader > > or the kernel, neither of which EVM can prevent. The phones > > Androids are often rooted by exploiting kernel or userspace > security holes. G1 was rooted by shell that was left running on > console... > > > Whether or not the phone is rooted, IMA-Appraisal, EVM, and > > the Digital Signature Extensions help protect against remote > > software attacks, and offline hardware attacks on individual > > files, but not against rooting itself. > > As far as I can tell, file signatures only prevent "offline hardware > attacks"; that is user trying to "attack" (== root) his own computer. > > Pavel Since when is my being able to detect and prevent unauthorized/malicious files on my own system (eg. device - VM) from being read/executed deemed evil?! Are you suggesting that we're better off not knowing the integrity or authenticity of a file? I suggest you read Dave's Integrity Overview whitepaper? Becoming involved in designing when/how new EVM encrypted key(s) are made available, determining if we need separate keyrings for EVM keys and the keys for appraising files(IMA-appraisal signatures), or defining the authorization mechanism required to add such keys (eg. LSM, extend capabilities), would be welcomed. Such discussions can take place on either the LSM or linux-ima mailing lists. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
