[OLPC Security] P_NETWORK and system responsiveness

Albert Cahalan acahalan at gmail.com
Sat Dec 1 18:45:12 EST 2007


On Dec 1, 2007 5:33 PM, Michael Stone <michael at laptop.org> wrote:

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

I'm happy to help, although my time is spread thin and
that's a pile of python code. I could write a shell script
for you. If you wish, you could translate from bash to python.
Would that be much help?

I'm thinking that the script might take a UID number as the
first argument. Maybe there would be two scripts, for turning
on and turing off. It may be better to have the script take a
list of UIDs to block, or a list of UIDs to allow, with all the
old state getting replaced.

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

No.

You could in fact do that. You'd need to run all other
code with one of those, probably SCHED_RR with the
lowest priority.

I was suggesting just the opposite though. Step back
and take a look at the situation we have. If a process
misbehaves severely, the user will hit the power button.
They will then NOT run that program again. This is OK.
It's very simple. There are no limits or UI issues to
bother with.

It is strongly desireable to let activities hog the CPU.
This allows activities to do reliable low-latency audio,
reliable experiment control, reliable radio modems, etc.
Thus the restriction of SCHED_FIFO and SCHED_RR
to root should be relaxed, as is done for many of the
Linux distributions that are meant for musicians.


More information about the Security mailing list