[OLPC Security] A mom's worries

[Marcus Leech]

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.

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.
> Currently there isn't a web server on the XO.
>
> Passwords are a non-issue. Physical access is the control.
> The ssh server won't allow access to an account without a password,
> so that's actually better than the strongest password you can
> possibly make. As for "su", that can be stopped in a number of
> ways. (enable the "wheel" group, file-on-file mount to make "su"
> be an empty file, etc.)
>
> Remember: every time you start an activity, a new throw-away user
> account is created just for running that activity. A previous
> implementation used vserver, which is OS-level virtualization
> similar to Solaris zones and FreeBSD jails. A future implementation
> could go back to that, or could switch to throw-away SE Linux
> security contexts. No matter the implementation details, this
> type of security prevents an attacker from messing with the
> user's files. Changing .bashrc just isn't going to work.
>   
In the particular case of the XO, no, changing bashrc can't be made to
work, because as you
  point out, each activity comes up in a "fresh" user context that gets
thrown away after
  each invocation.
>   
> 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,
  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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.laptop.org/pipermail/security/attachments/20071129/35eff5dd/attachment.pgp