[OLPC Security] P_NETWORK and system responsiveness

[Michael Stone]

Albert,

Since you seem to have deeper familiarity with the iptables stuff than I
do, would you be willing to contribute a patch on top of Marcus'
permissions work [1] that implements a basic on/off switch for IP-based
network access?

Also, regarding SCHED_FIFO and SCHED_RR: do I correctly understand you
to be saying that it's straightforward to use one of those schedulers to
guarantee system responsiveness in the face of a misbehaving activity?

Thanks,

Michael

[1]: http://dev.laptop.org/git?p=users/mleech/security;a=shortlog;h=permissions;


On Sat, Dec 01, 2007 at 01:55:04AM -0500, Albert Cahalan wrote:
> Marcus Leech writes:
> > 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.