On Wednesday 10 November 2010 08:56:20 Thomas Zimmermann wrote: > Am Mittwoch 10 November 2010, 08:38:58 schrieb [email protected]: > > Hello all, > > > > I've a question. I'm currently looking at opimd code with a view to > > > > perhaps rewriting it in vala. That, as far as I know, was always on the > > list of things to do and as an education to myself I thought it might be > > a usefull exercise. I mean it's not critical as opimd is there and works > > well so it's a handy starter exercise. > > Nice to hear, that someone tries to do fsopimd :) > > > Anyhow whilst mulling over things in my head I remebered that in recent > > weeks Android was hit by the shocking revelation that some installed apps > > were transmitting Personal Data to remote parties. Then there was the > > further shocking info that the iPhone suffers from the same problem. > > And now the next shocking, every PIM service i know has this problem. On > your PC every Game could access your akonadi/eds/windows adressbook > because they are all accessable with dbus or other "remote" technics. > > > I'm thinking that there ain't a whole pile you can do to secure PIM data, > > especially in an Open Source, implementation. That's what I'm thinking > > and I'll readily admit that I don't know squat about securing data. It > > seems to me that the first step to securing the data is saying that only > > the SHR supplied apps can access this data. That's not really good for > > choice which is one of the mail advantages of Open Systems. Even if you > > said that only SHR supplied apps could access this info if the apps > > source is readily available then you've achieved nothing. > > > > I've admitted that I know squat but is there anybody who can offer a > > clever idea which might be used to secure PIM data. I'm just curious. > > The only practical way i can think of is to ask the user if he allows that > app to access the PIM data. One can do that once for every app if it's > accessing the PIM data for the first time. > That way he can install his favorite contacts application, he is allowed to > give his contacts to facebook with such an app and so on... > > > And don't mention that the phone runs as root at present so it ain't the > > most secure. That's another discussion that I know squat about. In the > > ideal world where the phone did not run as root how would you secure PIM. > > I suppose that might well be the answer different user id's. Hmm only > > user "pim" or group "pim" can read pim data. Still that probably > > curtails third party developers writing a really cool app. They'll have > > to be able to access PIM. > > If we run the userspace as non root then we have just one user and he is in > the pim group or not. And as opimd is user specific content every user > should have it's own opimd. > Because of that i think a pim group isn't practicall. > And we are using dbus, which has no user/group system. Everyone who knows > the bus can access it. I don't even know if it's possible to get the name > of the programm which send the message to the bus... > If we can't then it's insecure by design. > > > Catch 22 you either have an open system that allows third party apps or > > you have secure data. > > Somehow yes :) > > But for now we have the advantage that we can access the source of every > app running on our phone. And so we can see if any app accesses opimd > which shouldn't be allowed. > But this works only as long as we don't have properitary apps. > > Regards > Thomas > > > PS: A better place for this discussion would be smartphones- > [email protected]
Bottom line then is that we rely on people inspecting the code of the apps being installed. It certainly works. If somebody wanted to write a malicious app they wouldn't have to access the data directly, as has beem mentioned, you'd only have to listen to DBus. Anyhow at present I can rest assured that my PIM data is secure on my Freerunner. Having said that I've never reviewed all the code in there ;-) _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
