Re: [9fans] security questions

[Venkatesh Srinivas <me@acm.jhu.edu>]

Devlimit / Rlimit is less than ideal - the resource limits aren't
adaptive to program needs and to resource availability. They would be
describing resources that user programs have very little visible
control over (kernel resources), except by changing their syscall mix
or giving up a segment or so. Or failing outright.

Prohibitions per-user are kinda bad in general - what if you want to
run a potentially hostile (or more likely buggy) program? You can
already run it in its own ns, but having it be able to stab you via
kernel resources, about which you can do nothing, is bad.

The typed allocator is worth looking at for speed reasons - the slab
allocator and customalloc have shown that its faster (from the
perspective of allocation time, fragmentation) to do things that way.
But I don't really see it addressing the problem? Now the constraints
are per-resource, but they're still magic constraints.

Something that might be interesting would be for each primitive pgroup
to be born with a maximum percentage 'under pressure' associated with
each interesting resource. Child pgroups would allocate out of their
parent's pgroup limits. Until there is pressure, limits could be
unenforced, leading to higher utilization than magic constants in
rlimit.

To give a chance for a process to give up some of its resources
(caches, recomputable data) under pressure, there could be a
per-process /dev/halp device, which a program could read; reads would
block until a process was over its limit and something else needed
some more soup. If the app responds, great. Otherwise, something like
culling it or swapping it out (assuming that swap still worked :)) or
even slowing down its allocation rate artificially might be answers...

If people are interested, there is some work going on in a research
kernel called Viengoos
(http://www.gnu.org/software/hurd/microkernel/viengoos.html) (gasp!
the hurd!) trying to address pretty much the same problem...

-- vs