On Mon, 2008-06-16 at 14:41 -0400, Kevin Dean wrote: > You dispute that the user data is the most important part of the > mobile device "experience?
No one (that I've seen thus far) is arguing that the user data is not the most irreplaceable (and to the user, important) part of a mobile device. What most everyone seems to be arguing is that running EVERYTHING as root for convenience is opening us up to a world of possibilities, all of them bad. > My previous e-mail has been clear - I WANT security on the device. > However, I simply don't beleive that the root/user seperation is the > most important consideration in that regard. You tossed out some great > security ideas, onces I'd personally put time into doing on my own > device, but with all due respect, you're saying my statements are > "nonsense" and then offering solutions that (while they work) aren't > what I was saying. Protecting user data is key so encryption and a > built-in, fully automated backup system is somethign I think would be > a GREAT thing to have. But it doesn't refute my point at all - a > non-root user can destroy the most critical part of the system and > doesn't need root to do it. Implimenting a root/user seperation itself > doesn't mitigate this risk. I agree that this risk needs to be > mitigated, I simply don't believe that the root/user split does much > to lessen the risks. The root/user separation is the most fundamental part of a security policy and here is why. Root is by its nature not only unrestricted but unrestrictable (I think I just made up a new word). A non-root user can only destroy the data that user "owns". Now while the conventional desktop, user "johndoe" owns all his MP3s and pr0n and thus can delete and otherwise destroy them; on the Moko platform, the extensive use of DBus makes destruction of the "most important part" more difficult. What I'm saying is that (Where possible) a daemon holds the important data (PIM data, calendar data, etc) and is capable of restricting what the user can do with it. The user account communicates with this daemon (via DBus or whatever) and gets the data the user wants while protecting the same. Both being normal users, they are not allowed to step on each other, but if the user is root, then someone with malicious intents can exploit that user account to step on the guardian account, either causing a DoS (crash) or actually manipulating/destroying data. I guess what I'm actually saying is that moving from an unrestricted account (root) to a restricted account (user) won't automagically buy us protection from all data-loss possibilities, but the mindset of moving to a normal user account is a core principle of a real security architecture. Ideally, something like an SELinux policy would be able to restrict capabilities without requiring different user accounts to do it (e.g. anything running as browser_r cannot talk to anything running as sms_r even though they're the same user). And if you're worried about deleting random data, a fairly simple chown/chmod will protect against that. That stuff doesn't work if the user you're guarding against is root. > That's correct if the data is encrypted but encryption isn't what's > being tossed around here. If all your data is stored in the clear, and > an intruder has physical access to the device, the distinctions > between root and non-root user don't matter. That's what I'm saying. That also depends on how long the malicious user has physical access and how fast the malicious user works. If the malicious user has only a few minutes and isn't proficient in cracking OM devices, the changes of damage are less. If the user can't keep good physical control of the device, then yes, they'll get pwn3d eventually, but no one I know of is that careless with their phones anymore. Even the non-geeky don't let their phones out of their sight for more than a few minutes. Now I'm not saying that such careless users don't exist, just that physical access and the root/user differentiation are not the same problem, and one should not override the other. Encryption is another matter, and one I will want addressed before too long. I've got some ideas on how it can be done, but I'll need to see more of the OM system "live" before I can begin to decide if my ideas are feasible or if they need changing. -KW _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
