Consider setting more restrictive default resource limits

(In reply to comment #0)
> /etc/security/limits.conf:
> * hard nproc 2048

This would prevent the easiest class of forkbombs from DoS'ing the computer, but
alone this really achieves not much more. In addition you need to limit the
number of logins, the memory, cpu time, etc. to provide a halfway effective DoS
protection.

Especially the maximum amount of allowed memory should be restricted dynamically
and depending on the size of available RAM; limits.conf does not offer this
functionality unfortunately.

*** Bug 14869 has been marked as a duplicate of this bug. ***

John, do you know whether there is a default configuration which is reasonably
safe and still does not break anything/too much?

I don't know, but I know for home desktop use relatively high settings are often
alright. For now all I'm concerned with is "huh? I downloaded a program off
the net but my computer froze" and "<w00td00d> hai hey wut huhu u shud open an
xterm or somethin n b liek :(){ :|:;};:" and people are dumb enough to do it.
For multi-user shell servers a better security scheme is needed.

Such trojans can just as easily delete the user's home directory, or other
things that cannot be prevented by ulimits. While ulimits can mitigate certain
security issues, trojan attacks are not among them.

This bug got pretty old now, and still there is no proposed solution that would
actually enhance something. I close this bug to not clutter up bz; if there is
something we can do about this topic, please reopen this bug or create a new one.

Reopening, as there are other scenarios (such as multiuser systems) where default limits would prevent the user from exploiting someone other than themselves

This bug has been open for so long? Why exactly? Patching this can be done very easily.

OffHand, it's far from easy to get this right. Current Linux PAM is just not flexible enough for that, and I doubt that there is a default restriction scheme which fits everywhere. (See comment 1)

Alright, fair enough. But why not change /etc/security/limits.conf to reasonable limits?
For instance 512 soft 1024 hard nproc? That seems a lot better than allowing an infinite spawn of processes. I doubt people, even power users, will need more resources. And if they need more, they probably know how to change the limits.

pam (0.99.7.1-4ubuntu1~ppa1) gutsy; urgency=low

  * Resynchronise with Debian (LP: #43169, #14505, #80431). Remaining changes:
    - debian/control, debian/local/common-session{,md5sums}: use
      libpam-foreground for session management.
    - debian/rules: install unix_chkpwd setgid shadow instead of setuid root.
      The nis package handles overriding this as necessary.
    - debian/libpam-modules.postinst: Add PATH to /etc/environment if it's not
      present there or in /etc/security/pam_env.conf.
    - debian/patches-applied/ubuntu-fix_standard_types: Use standard u_int8_t
      type rather than __u8.
    - debian/patches-applied/ubuntu-rlimit_nice_correction: Explicitly
      initialise RLIMIT_NICE rather than relying on the kernel limits. Bound
      RLIMIT_NICE from below as well as from above. Fix off-by-one error when
      converting RLIMIT_NICE to the range of values used by the kernel.
      (Originally patch 101; converted to quilt.)
  * Dropped:
    - debian/rules: bashism fixes (merged upstream).
    - debian/control: Conflict on ancient nis (expired with Breezy).
    - debian/libpam-runtime.postinst: check for ancient pam (expired with
      Breezy).
    - debian/patches-applied/ubuntu-user_defined_environment: Look at
      ~/.pam_environment too, with the same format as
      /etc/security/pam_env.conf. (Originally patch 100; converted to quilt.)
      Left out of "series" for now (LP: #113586).

pam (0.99.7.1-4) unstable; urgency=low

  * libpam0g.postinst, libpam0g.templates: gdm doesn't need to be restarted
    to fix the library skew, only reloaded; special-case this daemon in the
    postinst and remove the mention of it from the debconf template, also
    tightening the language of the debconf template in the process.
    Closes: #440074.
  * Add courier-authdaemon to the list of services that need to be
    restarted; thanks to Micah Anderson for reporting.
  * New patch pam_env_ignore_garbage.patch: fix pam_env to really skip over
    garbage lines in /etc/environment and log an error, instead of failing
    with an obscure error; and ignore any PAM_BAD_ITEM values returned
    by pam_putenv(), since this is the expected error return when trying
    to delete a non-existent var. Closes: #439984.
  * Yet another thinko in hurd_no_setfsuid and in
    029_pam_limits_capabilities; this code should really be Hurd-safe at
    last...
  * getline() returns -1 on EOF, not 0; check this appropriately, to fix
    an infinite loop in pam_rhosts_auth. Thanks to Stephan Springl
    <email address hidden> for the fix. Closes: #440019.
  * Use ${misc:Depends} for libpam0g, so we get a proper dependency on
    debconf.
  * 019_pam_listfile_quiet: per discussion with upstream, don't suppress
    errors about missing files or files with wrong permissions; these are
    real errors that should not be buried.
  * Drop the remainder of 061_pam_issue_double_free, not required for the
    original bugfix.
  * Drop patch 064_pam_unix_cracklib_dictpath, which is not needed now that
    we define CRACKLIB_DICTS in debian/rules.
  * Drop patch 063_paswd_segv, superseded by a different upstream fix
  * Split 047_pam_limits_chr...

Bleh. PPA upload caused this to auto-close. :(

pam (0.99.7.1-4ubuntu1) gutsy; urgency=low

  * Resynchronise with Debian (LP: #43169, #14505, #80431). Remaining changes:
    - debian/control, debian/local/common-session{,md5sums}: use
      libpam-foreground for session management.
    - debian/rules: install unix_chkpwd setgid shadow instead of setuid root.
      The nis package handles overriding this as necessary.
    - debian/libpam-modules.postinst: Add PATH to /etc/environment if it's not
      present there or in /etc/security/pam_env.conf.
    - debian/patches-applied/ubuntu-fix_standard_types: Use standard u_int8_t
      type rather than __u8.
    - debian/patches-applied/ubuntu-rlimit_nice_correction: Explicitly
      initialise RLIMIT_NICE rather than relying on the kernel limits. Bound
      RLIMIT_NICE from below as well as from above. Fix off-by-one error when
      converting RLIMIT_NICE to the range of values used by the kernel.
      (Originally patch 101; converted to quilt.)
    - debian/patches-applied/ubuntu-user_defined_environment: Look at
      ~/.pam_environment too, with the same format as
      /etc/security/pam_env.conf. (Originally patch 100; converted to quilt.)
  * Dropped:
    - debian/rules: bashism fixes (merged upstream).
    - debian/control: Conflict on ancient nis (expired with Breezy).
    - debian/libpam-runtime.postinst: check for ancient pam (expired with
      Breezy).

pam (0.99.7.1-4) unstable; urgency=low

  * libpam0g.postinst, libpam0g.templates: gdm doesn't need to be restarted
    to fix the library skew, only reloaded; special-case this daemon in the
    postinst and remove the mention of it from the debconf template, also
    tightening the language of the debconf template in the process.
    Closes: #440074.
  * Add courier-authdaemon to the list of services that need to be
    restarted; thanks to Micah Anderson for reporting.
  * New patch pam_env_ignore_garbage.patch: fix pam_env to really skip over
    garbage lines in /etc/environment and log an error, instead of failing
    with an obscure error; and ignore any PAM_BAD_ITEM values returned
    by pam_putenv(), since this is the expected error return when trying
    to delete a non-existent var. Closes: #439984.
  * Yet another thinko in hurd_no_setfsuid and in
    029_pam_limits_capabilities; this code should really be Hurd-safe at
    last...
  * getline() returns -1 on EOF, not 0; check this appropriately, to fix
    an infinite loop in pam_rhosts_auth. Thanks to Stephan Springl
    <email address hidden> for the fix. Closes: #440019.
  * Use ${misc:Depends} for libpam0g, so we get a proper dependency on
    debconf.
  * 019_pam_listfile_quiet: per discussion with upstream, don't suppress
    errors about missing files or files with wrong permissions; these are
    real errors that should not be buried.
  * Drop the remainder of 061_pam_issue_double_free, not required for the
    original bugfix.
  * Drop patch 064_pam_unix_cracklib_dictpath, which is not needed now that
    we define CRACKLIB_DICTS in debian/rules.
  * Drop patch 063_paswd_segv, superseded by a different upstream fix
  * Split 047_pam_limits_chroot_string_value up between
    008_modules_pam_limits_...

Why was this bug closed? It's still an issue in gutsy. (I mean :(){ :|:;}: still blocks the system)

Nothing will perfectly solve this, but with the new PAM, the nproc limits are in place, which was the best suggestion solution to this issue. I am open to other solutions, if they can be made to work for the general case.

Hi, Kees. What do you mean by 'the nproc limits are in place', i didn't understand.

I was expecting something like '* hard nproc 2048' in limits.conf, as said in comment #0.

With the PAM 0.99 upgrade in Gutsy, the kernel ulimits are finally being respected. As a result, nproc is being set now (instead of being "unlimited"). You can see this with "ulimit -u". (It is scaled based on physical memory.)

I've just been bitten by running out of virtual memory accidentally. Martin Pitt mentioned that allowed memory should be controlled as well, and this was missing so I had to hard reboot.

I'm going to set a system limit of perhaps half or three quarters available RAM.

Could a limit for allowed memory be added too please? I'm putting it here rather than opening a new bug as the subject is generally about ulimit and memory usage limits were mentioned from the start.

Please open a new bug (since it is a different feature request). Please attach any recommendations to the new bug, too. Thanks!

Done in bug 182960 - thanks