On Wed, Jun 18, 2008 at 4:26 PM, Knight Walker <[EMAIL PROTECTED]> wrote:
> 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. Actually, I think you've just sold me. I'm thinking about Openmoko a lot like I think of a desktop system (having looked at the way the data is on Om currently) that holds "everything is a file" and while it may be true, from an action perspective passing information through a non-root, non-user daemon exposes that information to the user in a way that's more than simply "dealing with a file". That's the goal of the ASU/zhone and it's a management case I wasn't even thinking of. Tradition bit me in the ass, thanks for spelling that one out for me, I like it a lot. :) > > 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 > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community