[OLPC Security] A mom's worries

[Albert Cahalan]

On Nov 29, 2007 11:33 PM, Marcus Leech <mleech at nortel.com> wrote:
> Albert Cahalan wrote:
> > Neither of those will work to attack the XO. You're spreading FUD.
> > You haven't even described a semi-plausible exploit.
> >
> I dunno, I always *assume* that something with a connection to the
> outside world is exploitable
>   in *some* way.  The Web activity is one such thing that *could* (I'm
> NOT saying that it *does*)
>   have exploitable vulnerabilities in it.

Sure, but you're not done. Get to something interesting.
(stolen files, video of the child, keylogger, corruption
of files, etc.)

> I don't think it's FUD to suggest that software isn't perfect, and some
> of those imperfections can
>   sometimes be exploited to violate security policies.  Fact of life.

Much more was said and implied. It certainly is FUD to
suggest that there is any practical likelyhood of some
crazy mess with systems getting pwn3d left and right.

Many of us can dream up things that are very unlikely.
Example: overflow in the Marvel firmware, make the wireless
device drop off the USB bus and then come back pretending
to be a mass storage device (USB key) with a FAT filesystem,
use an icon renderer exploit to run code as the journal,
and then overflow in the kernel to pwn the box. Could happen!
The laptop could also get hit by a meteorite. Not everybody
is skilled at judging security risk; it is spreading FUD when
you go waving vague theoretical possibilities in front of an
audience without computer security skills.

> > If it happens, it's a minor annoyance. The spam-bot dies when
> > the user closes the infected activity. Always remember that
> > the activities do not get access to the home directory. This is
> > not regular old UNIX security, where everything the user runs
> > will get full access to the user's files.
> >
> But any infected activity gets access to system resources in the same
> way as the
>   "host" user.   Last time I checked, rainbow/service.py didn't do
> anything special
>   to try and really hunt-down any background processes created by an
> activity,

That problem is not getting ignored. It has a trac number.
Even without implementing that, nothing will survive a reboot.

>   so to say that the spam-bot (or any other unintended malware-type-thing)
>   dies when the activity gets cleaned up is horribly misleading.
>
> > Getting out to the general OS would require a very serious
> > kernel bug. These are extremely rare. In the unlikely event
> > that such a bug started causing problems, the firmware will
> > let you install a fix. Firmware replacement, in case you were
> > thinking of it, is blocked by hardware before the OS gains
> > control of the CPU.
> >
> Getting out to the general OS requires nothing more than an exploitable
> bug in the application
>   code, and doesn't require a bug in the kernel.  But the result runs as
> an ordinary
>   (in this case, disposable) user.

That user is fairly well restricted by mount namespaces.
The code does a CLONE_NEWNS, bind mounts, etc.
(think "chroot", but more powerful)

By "getting out to the general OS" I mean to escape that,
and to get access to the goods like ~olpc and such.