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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.