Hey,
I read a document on securityfocus about fork bombinb a linux system.
Although they didn't speak about the effectiveness of resource limits I
guess that should be discussed because it's possible to make a linux
machine extremely slow (compared to FreeBSD for instance) even with well
configured resource limits.
I revised kernel/fork.c and I found a way to prevent this problem by
removing all associated processes with the parent, but that's far from
portable and should not be used for the sake of compatibilities. I guess
the function fork() should be revised.
And what about creating a 'maxprocs' sysctl var (even if left high) when
the resource limits problem is fixed? It would help security when it is
needed and wouldn't bother other applications. RLIMITs on login are not
trustworthy. It should exist a global limit in case someone could spawn
a shell without limits through some flawed application.
Thanks, and please advise.
you can limit the max number of processes by putting the following into /etc/security/limits.conf (on my distro, and quite a number of others according to google too)
* hard nproc <max # processes>
you can also limit quite a number of other things in this file, and other files in that directory.
redoubtable wrote:
> Hey,
>
> I read a document on securityfocus about fork bombinb a linux system.
> Although they didn't speak about the effectiveness of resource limits I
> guess that should be discussed because it's possible to make a linux
> machine extremely slow (compared to FreeBSD for instance) even with well
> configured resource limits.
> I revised kernel/fork.c and I found a way to prevent this problem by
> removing all associated processes with the parent, but that's far from
> portable and should not be used for the sake of compatibilities. I guess
> the function fork() should be revised.
> And what about creating a 'maxprocs' sysctl var (even if left high) when
> the resource limits problem is fixed? It would help security when it is
> needed and wouldn't bother other applications. RLIMITs on login are not
> trustworthy. It should exist a global limit in case someone could spawn
> a shell without limits through some flawed application.
>
> Thanks, and please advise.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Fri, 2005-03-25 at 04:17 +1000, Triffid Hunter wrote:
> you can limit the max number of processes by putting the following into /etc/security/limits.conf (on my distro, and quite a number of others according to google too)
>
> * hard nproc <max # processes>
>
> you can also limit quite a number of other things in this file, and other files in that directory.
I bet your PAM nonaware daemons started at boot are not affected by
those settings. The point is that if you gain access through a non-root
daemon started from boot scripts, you are no longer limited
by /etc/security/limits.conf.
Try to set hard nproc limits for user UID and run this from your boot
script:
#define UID 65534
#define MAX 65535
int pids[MAX];
int main() {
int count = 0; pid_t pid;
if (setuid(UID) < 0) { perror("setuid"); exit(1); }
while ((pid = fork()) >= 0 && count < MAX) {
if (pid == 0) { sleep(300); exit(); }
pids[count++] = pid;
}
printf("Forked %i new processes\n", count);
while (count--) kill(pids[count], SIGTERM);
}
You will see that even if user UID is limited
in /etc/security/limits.conf it will be able to fork many more
processes.
> > It should exist a global limit in case someone could spawn
> > a shell without limits through some flawed application.
I agree on this one. Or the RLIMIT_NPROC should be set to a lower value
by default.
--
Natanael Copa