moko running everything as root

[Knight Walker]

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