Re: Linux as resilient as BSD, resource hogging?

From: Kasper Dupont (kasperd@daimi.au.dk)
Date: 08/02/02 

From: Kasper Dupont <kasperd@daimi.au.dk>
Date: Fri, 02 Aug 2002 21:47:39 +0200

Jem Berkes wrote:
>
> I know that there are several ways that a regular user can, on a Linux
> system, disable/crash the system by doing things that use up all available
> resources. For instance, $0&$0 (using bash), or perl fork bomb -- and
> ulimit certainly doesn't stop everything.
>
> I'm guessing that BSD can withstand such things -- it's more popular among
> ISPs who have to deal with many, potentially untrustworthy users. Why can't
> Linux handle these resource hogging issues? What mechanisms are there in
> BSD that we can add to Linux?

I don't know what BSD does, but I could point out a few things that
could be done better in Linux. The following ideas is not aimed at
one particular resource, most of them can be used for all resources.

Ulimit is good, but it does not solve all problems like some people
tend to claim. We have a limited amount of a resource, and we try
to manage it by assigning a maximum to each user. Since not all
users will be using the resource at the same time, this is bound to
either be a waste because too many resources are never used, or be
not secure because too many users using resources at the same time
could kill the system. And in fact it might take as little as two
users to use all resources.

So just assigning a maximum to each user of course helps, but it is
just not enough.

Now it is important to clasify resources, some resources can be
given to a user and can be withdrawn without a problem. The first
obvious example of such a resource is CPU time. The rest of the
resources in this class really translate to being able to use some
other hardware for given periods of time.

Other resources cannot just be withdrawn once they have been
assigned, those obviously require more carefull management. The
resources in this class are storage space. Both harddiskspace and
space in some kernel data structures kept in physical RAM. When
mentioning harddiskspace I think about both space in filesystem
and swap, though they are not identical, space in filesystem is
often more longlived than space in swap.

Now, what can we do about those resources? The problem with ulimit
is that it kind of works backwards. The problem is having too
litle space left, but we manage the space being used by a user
rather than the space being left. An improvement would be to
specify how much space a user must leave rather than how much he
may use. But this is really not good enough either.

For the rest of this discussion I will assume all users is
equally important (except from root who is obviously more important
than all other users). Of course there could be policy decissions
to make some users more important than others, but I guess that
could quite easilly be incorporated in the principles.

With this assumption that all users are equally important we should
try to share resources equally between the users. AFAIK the kernel
currently doesn't do that. For one example users with more
processes get more CPU time than users with less processes, this
should change, but of course we should still fully use this resouce
if we have users enough for it.

Other resources are memory, open files, entries in the process table,
etc. For those resources we really want to keep some available for
root, but we also want to keep some available for other users even
when one user is abusing the resource. Trying to solve both desires
with a single limit is bound to fail, the point at which the single
user abusing a resource should be stopped is not the same as the
point where other users should be stopped to keep some resources
left for root.

What I would do is the following. First define two (preferably
configurable by root) limits. The first would be the amount of this
resouce a single user can use, the second would be the amount of
this resource that must be left for root. Obviously there should be
some room between the two to ensure when one user has used his
share, another user can still get some before hitting the root
limit.

This approach though has a major drawback: user1 allocates all he
can get, user2 allocates all he can get, now there is nothing left
for user3.

So I come up with another approach:

We still keep the amount reserved for root. If this limit has been
reached all other users are denied any more of the resource. When
the limit has not yet been reached, there will be some amount used
by root, some amount reserved for root, the rest will be available
for users. This should be equally shared between the users
currently needing this resource. Of course giving it all to those
users is not a good idea, because there might come another user in
just a moment. So we could say that of this space available to the
N users one (N+1)'th of the memory should be available to each user.
Now it can happen that a user gets beyond his allowed share,
because his allowed share shrinks as another user logs in. Since we
are talking about a resouce that cannot be withdrawn, we can only
prevent the user from allocating more. But we still have some
resources left, that we must manage cleverly. Now forget about all
the users which has already allocated too much, look what space is
left and what users are left. The remaining users should share the
remaining space according to the same principle, again there can
be some who has already allocated too much, repeat this algorithm
until you have a remaining group of users that can be allowed to
use more of the resouce, and a computed limit to how much they may
each use.

I really believe that approach would work, but it might need some
tweaking. When only one user is logged in, he should probably be
able to use more than 50% of some of the available resources.
However when many users are logged in, I might not keep enough
space free for more potential users.

The real clever algorithm would combine the configurability of
the first algorithm with the logic of the second and the ability
to use a policy making users not equally important. 

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razrep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

Relevant Pages

  • Re: Fork bombing a Linux machine as a non-root user
    ... > This isn't really a general security issue. ... to consume resources to the point that the whole system crashes. ... Similar limit is placed on a user allocating disk space. ... reserves about 5% of the disk which only root can use. ...
    (Fedora)
  • Re: 2.6.31-rc1: parisc: multiple PCI BAR collisions
    ... It cannot initialize many PCI devices (sym53c8xx, tulip, STI, ... - 0xf40053ff] collisions. ... I'm pretty sure this is a problem of the root bus resources not getting ...
    (Linux-Kernel)
  • [patch 39/71] x86/pci: insert ioapic resource before assigning unassigned resources
    ... commit 857fdc53a0a90c3ba7fcf5b1fb4c7a62ae03cf82 upstream. ... BIOS doesn't allocate resources for BAR 6 of devices under 8132 etc ... that multi-peer-root patch will try to split root resources to peer ... root resources according to PCI conf of NB ...
    (Linux-Kernel)
  • Re: Active Directory movements
    ... prod.local (root) all FSMO roles can't go over syst.local? ... >> In syst.local, the RID, PDC Emu, and IM roles resides ... >> I need move all servers, DC, resources, accounts .. ... How can i delete the root forest domain? ...
    (microsoft.public.win2000.active_directory)
  • Threads vs Forks in embedded environment : Some Conclusions
    ... as in our case where each process will execute its ... We do not require any additional libraries to supports forks as in case ... Linux has a unique implementation of threads. ... kernel as a normal process which just happens to share resources, ...
    (comp.arch.embedded)