fork()

fork()

[redoubtable]

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.

Re: fork()

[Triffid Hunter]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: fork()

[Natanael Copa]

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