[OLPC Security] Please read the spec and the discussion first, thanks. Was: Re: A mom's worries

Marcus Leech mleech at nortel.com
Fri Nov 30 08:16:31 EST 2007


Adric Net wrote:
> Since, as you acknowledge earlier, each Activity is started in it's  
> own UID, then it is trivial to make sure that all processes started by  
> that user and all of their children die when the Activity is  
> terminated, eg `slay 1003`. So, pointing out that 'weakness' is not  
> particularly helpful, but submitting a patch that adds that command to  
> activity tear-down might be.
>   
Pointing out a (possibly as-yet unidentified) problem is certainly
helpful, even in the absence of code to fix it.
  It's a bit like saying that the software QA department does nothing
useful, since they don't accompany their
  findings with code.  [But, FYI, I *have* been working with Mike Stone
on rainbow, including patches with
  code].
> Similarly, discussion of spamming is hopefully mitigated by the  
> default network rate limiting and cpu usage limiting of the platform.  
> If you see weakness in this plan that are not already discussed,  
> please share. Or submit patches :)
>   
Network rate limiting likely requires kernel patches that need lots of
deep thought before implementing.
  It happens that absolute CPU usage limiting is something that I've
recently been playing with in patches
  to rainbow that use ordinary rlimit() mechanisms when setting up an
activities environment.

I think it's useful in discussions to distinguish between what the
BitFrost spec says, and what is actually
  implemented.  A specification does not code make.  So, when I make
observations about the
  *current* state of affairs, it's with full recognition that a
fully-implemented BitFrost would take
  care of the issue.  But BitFrost *isn't* fully implemented, and some
of it will be a real slog
  to get working.

Some of the requirements of BitFrost will be moderately-to-extremely
difficult to achieve without kernel tweaks, and getting
  those tweaks into the upstream kernel will likely be an uphill battle.



-------------- 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/20071130/3333750c/attachment.pgp 


More information about the Security mailing list