Re: Linux kernels DoSable by file-max limit

["Kurt Seifried" <bugtraq () seifried org>]

> Solution: no temporary solution yet, there should be a global per user
> file limit, the reserved file descriptors should be given out under
> another uid/euid policy. The NR_RESERVED_FILES limit seems to me to be
> really low.

Huh. Simply limit users, PAM provides this capability, as do most shells.
From: http://seifried.org/lasg/users/

PAM
Almost all Linux distributions ship with PAM support making it universally
available. PAM limits provide a single standardized interface to setting
user limits, instead of having to write complex shell configuration files
(such as /etc/profile) you simply edit the "limits.conf" file. As well
applying limits selectively through the command shell is very difficult,
whereas with PAM applying limits globally, on groups or on individual users
is quite simple. Documentation is available on PAM usually in the
"/usr/share/doc/" tree. To enable PAM limits you need to add a line such as:

session         required        /lib/security/pam_limits.so
to the appropriate Pam configuration file (i.e. /etc/pam.d/sshd). You can
then define limits, typically these are in "/etc/security/limits.conf" or a
similar location. Because most of these limits are enforced by the shell the
system cannot log all violations of limits (i.e. you will be notified in
syslog when a user exceeds the number of times they are allowed to login,
however you will not receive a warning if the user tries to use more disk
space then they are allowed to).

The available limits are:

  core -- Limits the core file size (KB); usually set to 0 for most users to
prevent core dumps.
  data -- Maximum data size (KB).
  fsize -- Maximum file size (KB).
  memlock -- Maximum locked-in-memory address space (KB).
  nofile -- Maximum number of open files.
  rss -- Maximum resident set size (KB).
  stack -- Maximum stack size (KB).
  cpu -- Maximum CPU time (MIN).
  nproc -- Maximum number of processes.
  as -- Address space limit.
  maxlogins -- Maximum number of logins for this user or group.
  priority -- The priority to run user process with.

For example you can limit the amount of memory that user "bob" is allowed to
use:

user            hard    memlock         4096
This would place a hard (absolute) limit of 4 megabytes on memory usage for
"bob". Limits can be placed on users by listing the user name, groups by
using the syntax "@group" or globally by using "*".

core files can be created when a program crashes. They have been used in
security exploits, overwriting system files, or by containing sensitive
information (such as passwords). You can easily disable core dumps using
PAM, and generally speaking most users will not notice, however if you have
software developers they may complain.

*               hard    core            0
fsize is generally a good idea to set, many users will have a large
filesystem quota (i.e. tens of megabytes to several hundred or several
gigabytes), however if they are allowed to create a single file that is
abnormally large they can easily hog disk I/O resources (i.e. create a large
file and copy/delete the copy repeatedly). Setting this limit globally can
also prevent an attacker from trying to fill up the partitions your log
files are stored on, for example if you only have a single / partition an
attacker can easily fill it up by generating a lot of log events.

@notroot        hard    data            102400
Of course limiting CPU time is one of the classic administrative tasks, this
is very useful for preventing run-away processes from eating up all the cpu
time, and it ensures that if a user leaves something running in background
(such as a packet sniffer) it will eventually be killed. Limiting CPU time
will have several side effects however, once of which will be limiting the
amount of time a user can spend logged in (eventually they will run out of
CPU time and the session will be killed), this can lead to problems if users
spend long periods logged in. As well depending on the CPU(s) present in
your machine the limits can vary greatly (one minute on a 386 is quite a bit
different then one minute on a 1.3 GHz Athalon).

@students       hard    cpu             2
Limiting the number of times a user can login is strongly advised, for most
situations users should not need to log in to a server more then once, and
allowing them to do so let's them use more resources then you might intend.
As well it can be used to detect suspicious activity, if users know they can
only login once then attempts to log in multiple times can be viewed as
suspicious activity (i.e. an attacker with a stolen password trying to
access the account).

@users          hard    maxlogins       1
Additionally when someone violated this limit it will be logged in syslog:

Apr 15 15:09:26 stench PAM_unix[9993]: (sshd) session opened for user test
by (uid=0)
Apr 15 15:09:32 stench pam_limits[10015]: Too many logins (max 1) for test
Soft limit violations will not be logged (i.e. a soft limit of 1 and a hard
limit of 2).



Bash
Bash has built in limits, accessed via "ulimit". Any hard limits cannot be
set higher, so if you have limits defined in /etc/profile, or in the users
.bash_profile (assuming they cannot edit/delete .bash_profile) you can
enforce limits on users with Bash shells. This is useful for older Linux
distributions that lack PAM support (however this is increasingly rare and
PAM should be used if possible). You must also ensure that the user cannot
change their login shell, if they use "chsh" to change their shell to ksh
for example the next time they login they will have no limits (assuming you
cave not put limits on ksh). Documentation is available on ulimit, log in
using bash and issue:

[root@server /root]# help ulimit
ulimit: ulimit [-SHacdflmnpstuv] [limit]
    Ulimit provides control over the resources available to processes
    started by the shell, on systems that allow such control.  If an
    option is given, it is interpreted as follows:

        -S      use the `soft' resource limit
        -H      use the `hard' resource limit
        -a      all current limits are reported
        -c      the maximum size of core files created
        -d      the maximum size of a process's data segment
        -f      the maximum size of files created by the shell
        -l      the maximum size a process may lock into memory
        -m      the maximum resident set size
        -n      the maximum number of open file descriptors
        -p      the pipe buffer size
        -s      the maximum stack size
        -t      the maximum amount of cpu time in seconds
        -u      the maximum number of user processes
        -v      the size of virtual memory

    If LIMIT is given, it is the new value of the specified resource.
    Otherwise, the current value of the specified resource is printed.
    If no option is given, then -f is assumed.  Values are in 1024-byte
    increments, except for -t, which is in seconds, -p, which is in
    increments of 512 bytes, and -u, which is an unscaled number of
    processes.
To disallow core files (by setting the maximum size to 0) for example you
would add:

ulimit -Hc 0
To set limits globally you would need to edit "/etc/profile", of course this
will also affect root, so be careful! To set limits on groups you would need
to add scripting to "/etc/profile" that would check for the user's
membership in a group and then apply the statements, however doing this with
PAM is recommended as it is a lot simpler.





Kurt Seifried, kurt () seifried org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/