[OLPC Security] Please read the spec and the discussion first, thanks.

[Albert Cahalan]

Marcus Leech writes:
> Adric Net wrote:

>> 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.

Right. It's a good thing somebody did that years ago. :-)
(not that I think this is a critical thing to limit)

Use the iptables command. Match on UID. You have a number of choices
here. The ones that look interesting are:

--limit --limit-burst --quota --set-dscp --set-dscp-class
--set-mark --set-tos --mark --length --hashlimit --dscp
--dscp-class --connlimit-above --connlimit-mask --connbytes
--connbytes-dir --connbytes-mode

If that isn't enough for you, the tc command offers some
extra stuff. Mark the packets with iptables, and then use
the tc command to act on that.

> It happens that absolute CPU usage limiting is something that I've
> recently been playing with in patches

Why? It's a single-user machine. A better idea would be to go the
other way. SCHED_FIFO and SCHED_RR are useful for many things.
(computer-in-the-loop performance audio, general data collection
for experiments, soft modems, etc.)

The jack audio developers have a kernel module that lets realtime
features be made available based on GID. A simpler solution is to
just comment out the security check. I'd probably give 1/3 of the
realtime levels to activites that desire it at install time, and
an extra 1/3 to the olpc user.

> 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.

My default assumption when talking about such matters is that we
are discussing the things that are likely to be implemented when
serious deployment is well under way. That's when the system
first becomes interesting for malware writers.