On Fri, Oct 1, 2010 at 4:06 PM, Chris Palmer <[email protected]> wrote:
> >> processes running as the same UID. If somebody pops Firefox, your SSH > >> keys, email, documents, et c. are all at risk. > > > > Arguably that is a security flaw, not a design/interface flaw. > > I don't know what distinction you're trying to draw there. OS X, > Firefox, SSH, et c. are working as intended. > > The Unix/NT security model is: UIDs are protected from each other, but > not from themselves or from root. The design is outdated and no longer > sufficient, but it made a bit more sense when it was invented. Android > uses the old mechanism in a new way, to be relevant in a world of code > from many sources. > > The kernels may, and do, have implementation flaws that allow > malicious programs to break that guarantee. That's a serious problem > --- for all platforms. > > OSX in your example isn't working as intended - the intended use of gdb is not to allow users to bypass keychain access restrictions any more than the intended use of the recovery mode (on a galaxy) is to allow users to bypass android platform security. I don't know what purpose the primer on unix user security was, but thanks I guess. It has - as you sort of pointed out - very little to do with this discussion. Lets backtrack a bit - it was, primarily, a UI discussion at the time: Also, the problem is not specific to Android --- Android just surfaces >> these pre-existing concerns and deals with them better. Not perfectly, >> but better. Other platforms give all apps all the goods all the time, >> no permission screen required. >> >> > OSX keychain is a great counter-example, and passes the grandmother test: > an app can get account (or other secret) information by asking the user. The > user can say "yes", "no", or "always yes"/"always no". (Since its a general > purpose system, the user may be required to authenticate - not amazingly > feasible on android, although an optional security PIN could work.) Windows > popup-of-doom (going all the way back to ... blackice? or the other one? > anyway, >10 years ago) handle it better. "This app is attempting to do this > SPECIFIC thing, right now." Not "Please allow this app to do some or all of > this large, vague list, at some point." > If we're to continue applying the criteria you listed later (-can- it be bypassed somehow) then we should junk all the permissions entirely, since they aren't 100% effective. Including the existing android permissions. As an attempt to move the discussion forward, what is to stop an app from 1 developer from collecting information and sending it as an intent to a different app to be distributed? At least in the proposed model, there is a chance that a user will see "AppFoo wants to connect to the internet." and think "That's weird, I was using my credit-card-number saving app. Why is AppFoo running suddenly?" -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
