It describes how to DoS OpenBSD by using all available file descriptors,
this is done by serveral processes.
It can't be done with only one process, because of the "openfiles"
limit. But thats no problem - a user of the login class "default" is
allowed to have up to 128 processes, each may have 64 descriptors. Thats
about 8000 file descriptors - for one user of the login class default.
kern.maxfiles=1772 seems to be the limit of file descriptors concerning
the system. If this limit is reached, nobody can work anymore, because
nobody can open any files. Even root just can't login, because there is
no file handle to open the libc shared library.
I tested this issue on two different machines, it works for me.
I increased kern.maxfiles to 16.000 and limited macproc to 64 to
prevent one user of the login class "default" to stop my hole system.
Would it be nice to change this per default to achieve the ideal of
being "secure by default"?
Has such a high kern.maxfiles disadvantages?
Did i miss something?
| /"\ ASCII Ribbon | Jonathan Glaschke - Lorenz-Goertz-Stra_e 71,
| \ / Campaign Against | 41238 Moenchengladbach, Germany;
| X HTML In Mail | jabber: [hidden email] | / \ And News | http://jonathan-glaschke.de/
[demime 1.01d removed an attachment of type application/pgp-signature]
On Thu, Apr 06, 2006 at 12:00:28AM +0200, Jonathan Glaschke wrote:
> prevent one user of the login class "default" to stop my hole system.
> Would it be nice to change this per default to achieve the ideal of
> being "secure by default"?
> Has such a high kern.maxfiles disadvantages?
> Did i miss something?
Well, it's not a security hole, it's a default behaviour ;)
You could also complain, that we don't have disk quota per default and
users can DoS(tm) system.
Nevertheles, i've run into this problem on one of my servers - on
others, those settings are sufficient.