moko running everything as root

[Kevin Dean]

On Wed, Jun 18, 2008 at 4:26 PM, Knight Walker <moko at kobran.org> 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 at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>