public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Natanael Copa <mlists@tanael.org>
To: Kyle Moffett <kmoffett@tjhsst.edu>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: forkbombing Linux distributions
Date: Wed, 23 Mar 2005 21:26:53 +0100	[thread overview]
Message-ID: <1111609613.20101.24.camel@nc> (raw)
In-Reply-To: <fa82dfa71dabb4d0b3df9a6c2b776349@tjhsst.edu>

On Wed, 2005-03-23 at 14:38 -0500, Kyle Moffett wrote:
> On Mar 23, 2005, at 09:43, Jan Engelhardt wrote:
> >> brings down almost all linux distro's while other *nixes survives.
> >
> > Let's see if this can be confirmed.
> 
> Here at my school we have the workstations running Debian testing. We
> have edited /etc/security/limits.conf to have a much more restrictive
> startup environment for user processes, limiting to 100 processes per
> user and clamping maximum CPU time to 4 hours per process.

Thats great. I was was thinking of the default settings. (its even
possible to lock down a windows machine to be "secure")

Also the daemons started from bootscripts that is not aware of PAM is
not affected by those settings. So an exploited security flaw in a
service would allow an attacker to bring the system down even if the
service is running as non-root.

Try running this from a boot script and you'll see that even if this
process is setuid, it will be able to fork more than 100 processes per
user:

/* this program should be started as root but it changes uid */

#define TTL 300
#define MAX 65536
#define UID 65534

int pids[MAX];
int main(int argc, char *argv[]) {
        int count = 0; pid_t pid;
        if (setuid(UID) < 0) {
                perror("setuid");
                exit(1);
        }
        while ((pid = fork()) >= 0 && count < MAX) {
                if (pid == 0) sleep(TTL);
                pids[count++] = pid;
        }
        printf("Forked %i new processes\n", count);
        while (count--) kill(pids[count], SIGTERM);
        return 0;
}


> In any case, I think
> that while there could perhaps be a better interface for user-limits
> in the kernel, the existing one works fine for most purposes, when
> combined with appropriate administrative tools.

My point is, the default max allowed processes per user is too high. It
better to open up a restrictive default than locking down an generous
default.

--
Natanael Copa



  reply	other threads:[~2005-03-23 20:28 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-21  3:06 forkbombing Linux distributions William Beebe
2005-03-21  3:22 ` Dave Jones
2005-03-21  3:26   ` William Beebe
2005-03-21  3:27 ` Peter Chubb
2005-03-21  5:14   ` Grant Coady
2005-03-21  7:41     ` Jan Engelhardt
2005-03-22 11:26 ` Hikaru1
2005-03-22 11:49   ` Jan Engelhardt
     [not found]     ` <20050322124812.GB18256@roll>
2005-03-22 12:50       ` Hikaru1
2005-03-23 10:56         ` aq
2005-03-23 12:37           ` Natanael Copa
2005-03-23 13:04             ` aq
2005-03-23 13:38               ` Jan Engelhardt
2005-03-23 13:54               ` Natanael Copa
2005-03-23 14:20                 ` Måns Rullgård
2005-03-23 14:43                 ` Jan Engelhardt
2005-03-23 15:04                   ` Natanael Copa
2005-03-24  7:07                     ` Jan Engelhardt
2005-03-24 10:05                       ` Natanael Copa
2005-03-23 19:38                   ` Kyle Moffett
2005-03-23 20:26                     ` Natanael Copa [this message]
2005-03-23 17:05                 ` aq
2005-03-23 18:05                   ` Paul Jackson
2005-03-23 18:44                     ` aq
2005-03-23 20:15                       ` Natanael Copa
2005-03-23 20:48                   ` Natanael Copa
2005-03-23 13:45             ` Erik Mouw
2005-03-23 14:03               ` Natanael Copa
2005-03-23 13:53     ` Max Kellermann
2005-03-23 14:23       ` Natanael Copa
2005-03-23 14:27         ` Max Kellermann
2005-03-23 14:44           ` Natanael Copa
2005-03-23 14:52             ` Max Kellermann
2005-03-23 15:18               ` Natanael Copa
2005-03-26 10:37 ` Tux
2005-03-28  8:03   ` Natanael Copa
  -- strict thread matches above, loose matches on Subject: below --
2005-03-22 17:09 Natanael Copa
2005-03-28 17:28 Matthieu Castet
2005-03-28 17:56 ` folkert
2005-03-28 19:33   ` Jan Engelhardt
2005-03-28 19:39     ` folkert
2005-03-28 20:35       ` Renate Meijer
2005-03-29 12:31 ` Natanael Copa
2005-03-30 23:46 ` Felipe Alfaro Solana
2005-03-31  6:55   ` Natanael Copa
2005-03-31  7:09     ` Jacek Łuczak
2005-03-30 17:40 Jacek Łuczak
2005-03-31 10:00 ` Natanael Copa
2005-03-31 17:11   ` Lee Revell
2005-04-05  9:47     ` Natanael Copa
2005-04-05 10:18       ` Jacek Luczak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1111609613.20101.24.camel@nc \
    --to=mlists@tanael.org \
    --cc=jengelh@linux01.gwdg.de \
    --cc=kmoffett@tjhsst.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox