On Thu, Mar 15, 2012 at 1:30 PM, Justin Lebar <justin.le...@gmail.com> wrote: > To boil this proposal down into its key points: > > 1) App lists desired permissions in its manifest. > 2) App store approves permissions on app's submission. > 3) User approves permissions at install time. > 4) Some permissions need to be granted by a trusted app store before > the user can grant them. > > > == Lazily approving permissions ==
wiki section heading! > I'd like us to consider changing (3) to > > 3a) User approves permissions when app touches the relevant API. this is a superb idea. where is it recorded on the wiki? *nudge, nudge* technically it's damn hard though. * the correct place for verifying permissions is the kernel (not userspace). it is really really important *not* to have a permissions system which is in userspace: it'd be security by cooperation. which is a bit like the unix "good will" virus, if anyone remembers that :) * thus now what you're saying is that the application must be PAUSED... at the point at which the actual system-level function call occurs! * that means that there needs to be an event notification system from kernelspace to userspace (!) * where the notification fires *another* application (a popup)... bearing in mind now that one of the threads/processes/executables is presently paused so you *must* not have any mutexes or other locks which could result in deadlock here.... * the userspace popup gets a yay or nay from the user * the userspace application hands the answer back to kernelspace * kernelspace says "yay" or "nay" to the system-call that's blocking * the userspace application carries on its merry way. so yes a simple decision that is technically possible that has massive implications at an implementation level. no blocking for access to the screen, for a start! and the "popup" application itself must also not fire off any security questions which also requires a "yes/no" interactive popup else you'll get recursive melt-down. whoops. > == Designing APIs to fail gracefully when permission is not granted == > > Since users may disallow permission for an app to use any API, we need > to design our APIs to fail gracefully when permission is not granted. > > Page tries to read contact data. We ask if that's OK. If not, then > we present an empty contact book, instead of throwing an exception or > something. Apps won't be designed to handle the case when permission > is not granted, so we need to make not-granted behave similarly to > granted, from the page's perspective. > > Maybe this is obvious, but I wanted to make sure we're all on the same > page here. "obvious" or not, it's important that it go into the functional analysis document (wiki page). this is programming. nothing's "obvious", especially where security is concerned. it's "obvious" that you should not de-reference a null pointer, so why do people write code that does that, eh? he he :) > == Trusted app stores and sophisticated users == > > How will sophisticated users work around requirement (4), that > sensitive APIs can only be granted by trusted app stores? I realize > this is a fine line. > > For distributing beta software, perhaps we could have an "at your own > risk" store, with lots of scary warnings. debian packaging has a comprehensive system for dealing with this. *dig*, *dig* - surely people know this, right? it's "obvious" to me that debian and other packaging systems have this? ;) the package database is divided down into: * stable - the latest thoroughly-tested release. upgrades are guaranteed to work. * backports - makes available new (stable) stuff for older releases * testing - more comprehensive testing: gets turned into "stable" every 9-18months * unstable - stuff that has no complaints for 2 weeks goes into testing * experimental - really really untested. like... really just you'd be foolish to use it. * volatile - this is just data that keeps changing also there are lines in /etc/apt/sources.list for security-updates (usually for stable) so that even if people stick with "stable" they can still get updates for severe flaws in the software. so when i said that debian distribution maintenance is extremely comprehensive, i really wasn't arseing about: it really really is just exceptionally thorough. 1000 opinions over 20 years _does_ eventually result in something that actually works, if for no other reason than that 1 person does all the work to solve a particular problem by ignoring the other 999 opinions :) l. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
