ulimit, maxproc/openfiles limits

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ulimit, maxproc/openfiles limits

Jonathan Glaschke-2
Hello.

I recently saw this article: http://networkpenetration.com/fd.html

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?

Regards
Jonathan

--
 | /"\   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]

Reply | Threaded
Open this post in threaded view
|

Re: ulimit, maxproc/openfiles limits

Lukasz Sztachanski
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.

                                - Lukasz Sztachanski


--
0x058B7133 // 16AB 4EBC 29DA D92D 8DBE  BC01 FC91 9EF7 058B 7133
http://entropy.pl